The channels MSN is shutting down were built for a different platform.

MSN spent the last two years absorbing a huge volume of syndicated content, and it is now cleaning up after that growth. Sites are being throttled, and channels are being closed. It is landing on small publishers and on large ones, and a good share of the operators it lands on are not amateurs. Some of them have been syndicating for a decade.
Alongside them is a newer group: creators with real audiences somewhere else, looking at MSN as another revenue line, working from the assumption that you download the video you already made, upload it, and you are in business.
Both groups are making the same structural mistake, and it has almost nothing to do with effort or quality. Practically nothing in a typical syndicated video operation was designed for MSN. The repost habit, the titles and thumbnails, the unit of measurement, the daily number, and the feed architecture underneath all of it. Every one of those arrived from somewhere else, usually from a platform whose rules point in the opposite direction, and they arrived as defaults nobody chose out loud.
Two years ago most of that was survivable. It is not survivable now, and MSN will not tell you which of your inherited defaults is the one costing you.
I wrote here two weeks ago about what the platform does to your content after it publishes and why the acceptance number on your dashboard cannot see any of it. This is the other half of the same operation and the earlier half in time. Not what MSN does to your work once it is live, but what your operation was already carrying before it published anything.
The repost habit
On YouTube, running the same asset across related channels is ordinary practice, and refreshing an old upload is a legitimate growth play. Those instincts travel with the team.
MSN reads them completely differently. Microsoft's documentation is explicit that previously posted content gets rejected even with a changed date. Sibling channels republishing the same licensed asset is the single clearest way to trigger duplicate suppression, and without clean canonical tags the ranking system cannot work out which version is authoritative, so it protects itself by promoting none of them.
The part I want to be precise about is that almost nobody thinks they are doing this. Very few operators would publish an identical file twice on one channel. What they believe, and it is a reasonable belief anywhere else, is that a sibling channel is a different channel, so the same asset can run on both. Or they change the date, or they swap the headline, leave the rest, and consider the piece refreshed.
A re-upload is a duplicate. A new cut with a new angle, a new headline, and a new thumbnail is new content. That line is not a matter of degree, it is a classifier boundary.

None of which makes reposting wrong. The MSN audience skews evergreen, and a deep back catalog performs well, so done properly this is one of the most efficient plays on the platform. The right mix of new to reposted gets set per channel rather than across the operation, and it moves with how deep the catalog is and how much authority that channel has already built. What does not move is the standard. Every repost gets a new cut, a new thumbnail, a new headline, and a fresh abstract. None of them get the original file with a new date.
The packaging
Titles and thumbnails come over intact, and they were built for a video search engine. MSN is a news feed, and a news feed penalizes several of the exact patterns a search engine rewards.
Thumbnails cannot carry text, arrows, or emojis, which alone disqualifies most of what already exists. MSN also restricts a whole category of imagery that catches nearly every team arriving from social, and it runs considerably wider than the obvious cases. Computer vision and OCR read the picture itself, so this is enforced on what the image contains, not on how the file is named.
The practical consequence is a production line nobody budgeted. Roughly twenty original thumbnails a day is about three hours of daily work, which makes it the largest efficiency target in the operation and one that almost never appears in a scope, because the people writing the scope are thinking about video.
Audio arrives inherited too. MSN allows zero profanity, not even mild, in the first twenty seconds, and there are defined limits past that point as well. Moderation processes the audio track and the transcript, so a clean caption does not clear the piece. What matters operationally is sequencing: run the transcript pass before edit lock, and the fix is an edit decision. Run it after, and the fix is a re-upload, which drops you back into the duplication problem.
Then there is categorization, which is the quietest of the group. Assets tagged as generic "Video" instead of mapped to a real vertical leave the recommendation engine nowhere to place them inside the thematic sections where discovery happens. Nothing gets rejected, the work simply never surfaces.
The unit of measurement
This one is specific to video and worth separating, because the editorial side of MSN does not work this way and the two get conflated constantly.
MSN video revenue is consumed seconds multiplied by revenue per second consumed, which varies by market and by surface. Not per view, not per engaged view, not per post. Ten short pieces earn what one long piece earns if they produce the same consumed seconds, and they cost several times more to make. The guidelines point to three to five minutes for the best completion behavior. A ninety-second trailer can post an excellent click-through rate and earn close to nothing. Verticals under twenty seconds are a documented red flag that tends to get rejected, and MSN converts verticals to 16:9 rather than serving them natively.
There is also a second surface most imported operations never touch. Watch is the video feed and skews mobile. Embedded is video placed inside articles, and it skews desktop, which is where most MSN consumption happens. MSN is a desktop, work-hour platform, and traffic falls on weekends and holidays. That is close to the inverse of the YouTube pattern these libraries were built around, and the seasonality alone misleads teams reading their first month of data.
The feed
Everything above is visible if you look. This one usually is not, and it is where the real exposure sits.
Teams design their production with care and inherit their feed architecture without examining it once. That is the pattern I see most often, and the reason it matters is that MSN does not enforce at the level you produce at. You make videos, what gets switched off is the feed.
Feeds carrying persistent errors are placed on a control list and lose auto-publishing entirely. That is the ingestion channel closing and everything queued behind it stopping with it, caused by an accumulation that no individual piece would have triggered on its own. If several channels share one feed, a moderation problem on your riskiest channel takes down the ones that never did anything wrong.

Above the feed sits brand authority, which partly drives MSN ranking, so a bad run cascades into lower visibility for whatever comes next, and repeated violations escalate to the brand rather than to the individual asset. That is the full path from an inherited default to a closed channel: a habit that was correct on another platform, accumulating against a feed, degrading a brand, ending an account.
This is also where the number worth watching lives. Auto publishing pass rate, or read inversely, loss rate: the percentage of what you submit that clears the automated classifiers without human intervention. It has a hard operational consequence attached to it. Rejection rate belongs beside it, and rejection history is worth defending, because an erroneous rejection left unappealed still counts against the feed's record even though the appeal mechanism exists and resolves quickly.
The daily number was inherited too
The last default is the one that drives all the others, and it usually comes from a scope written before anyone had seen a dashboard.
A skilled editor working full time, producing genuinely differentiated pieces at the quality bar MSN requires, sustains a fraction of twenty a day. Not a cautious fraction, either. That is the rate that holds up across months without the work drifting. And a repost of material already cut for another channel takes a small fraction of the time a new piece takes, which is exactly why the shortcut is so attractive and so expensive.
Twenty pieces a day is several producers, or it is duplication. The target does not care which one you pick, and it will get one of them.

So when volume rises and consumed seconds do not, the operation is manufacturing cost, and the correct move is to produce less. That is the least popular recommendation in this business, and it is usually the right one.
The first question I ask on a syndication account is no longer, "What are you publishing?" or "How much?" It is what this operation brought with it, and from where. Almost every expensive thing I find traces back to a decision that was correct on a platform nobody is being paid by anymore.
There is a lot more underneath this than fits in one piece. The exact thresholds, the mix we run per channel, what a real production day costs in hours, and the order we take an account apart in. Most of it came out of putting our editorial, video, and recruitment teams on the same problem at the same time. It is specific enough that it is worth going through against a particular operation rather than in general. If you are running channels on MSN right now and any of the above sounds like your week, that conversation is one message away, and I am glad to have it.
Milan Lab builds and operates editorial, content, and software teams for digital publishers and media companies. See how we work.
Working through this in your own operation?
It's the kind of problem we build teams to solve.
See how we work