Moving a WordPress tube with tens of thousands of videos without losing its indexing

Most migration advice is written for a blog with two hundred posts. A tube is a different animal. Tens of thousands of video pages, category and tag archives, years of permalink changes, a good share of embeds that died quietly, and a plugin setup that stored everything in post meta. Move that carelessly and you don't lose a few rankings, you lose the site for a quarter.

We've written the long version on the blog, Moving a WordPress adult tube without losing its rankings. This is the shorter, forum version, with the parts that only show up at scale. It applies whatever you're moving to, Jimp or anything else.

What Google actually needs from you

Google's own page on site moves with URL changes is short and worth reading in full. Three lines in it carry most of the weight for a tube. Use permanent server-side redirects, 301 or 308. Keep them "for as long as possible, generally at least 1 year". And expect a medium site to take "a few weeks or more" before Google shows the new URLs instead of the old ones, with larger sites taking longer.

That last one matters for your nerves. A tube with forty thousand pages is a large site by Google's standards, so the switch plays out over weeks, sometimes months, and the traffic curve wobbles along the way. People panic in week two and start changing things, which is the one move that reliably makes it worse.

Count the dead before you move anything

On a tube fed by an embedder for years, a lot of videos are gone at the source. From the WordPress admin they still look like posts. From the visitor's side they're an empty player, and Google has usually noticed long before you have.

Moving those as pages is how a migration turns into a penalty that looks like bad luck. You hand the new site thousands of empty pages on day one, and that's the exact profile of a mass-generated site. So the first job isn't the export, it's the inventory. For each post, is the video still served by its source? The thumbnail is the quickest tell, since a removed video usually takes its thumbnail with it and a thumbnail answering 404 is easy to test at scale, far easier than loading every player.

Split the result into two lists. Living videos move as pages. Dead ones become redirects to the category they belonged to, so whatever link equity they still carry lands somewhere that makes sense, and nobody opens an empty page. Don't delete the dead posts on WordPress while you work, you'll want them for the redirect map.

The redirect map is the whole job

At small scale people map redirects by hand. At forty thousand pages you need the map generated from the database, and it needs to cover more than the obvious.

Full paths, not slugs. A tube that's been through a permalink change or two has /video-slug/, /category/video-slug/ and /2021/04/video-slug/ living side by side, sometimes all indexed. The redirect has to match the whole path. Matching on the last segment alone works until two videos share a slug, which on a tube happens sooner than you think.

Duplicates too. Embedders happily import the same video twice from two feeds or two categories. Both old addresses exist, maybe both have links. Pick one survivor (the oldest post is a sane rule) and point every other address at it.

Then the pages that aren't videos. Category archives, tag archives, the author page nobody meant to publish, paginated listings. Each one either maps to an equivalent page on the new site or goes to the closest thing that exists. Sending everything to the home page is what Google treats as a soft 404, which throws the signal away.

Before switch day, take a sample of a few hundred old URLs, from your analytics and from the pages Search Console says get impressions, and run them through the map. Every one should land on a page about the same thing. If ten out of three hundred land wrong, the pattern behind those ten is wrong for thousands.

Never let both sites be indexed at once

Building the new site takes days, maybe weeks. During that time it lives on a temporary address, and it must answer noindex to every crawler. Not "it isn't linked anywhere", actually noindex. Unlinked sites get found all the time, through a shared preview, an analytics referrer, a sitemap somebody submitted by habit.

If Google indexes the new site while the old one is live, you've got two domains carrying the same forty thousand titles. The new one is the copy. When you switch, you're switching to the site Google already filed as a duplicate, and the redirects have to undo that before they can do anything else.

The noindex comes off at the same moment the domain switches and the redirects start answering. Same minute, ideally. A day of 404s between the two costs rankings that take months to win back.

Media the WordPress hosted itself

Embeds are the easy part, the video lives at the tube and keeps playing from there. The trap is everything your WordPress stored itself. Uploaded MP4s, hover previews the plugin fetched and kept, local thumbnails. All of that sits in wp-content/uploads, and the day you cancel the old hosting, every page that relied on it breaks.

Copy those files during the move, not after, and check the total size before you start, because on a big tube it's often far more than people expect. If you copy video, copy it into something that streams in several qualities rather than serving a whole MP4 to every visitor. Whole MP4s from shared hosting are half the reason those pages were slow in the first place.

Fix the text while nobody is watching

Here's the part that has nothing to do with the move and a lot to do with how the old site ranked. On a mass-embedded tube, the titles and descriptions are the feed's. The same feed runs on hundreds of sites. Google has always known your pages were copies of everyone else's.

A migration is the one moment you can fix that at scale for free, in ranking terms, because the new site isn't indexed yet. Rewrite the living videos before the switch, and the pages that inherit the old URLs arrive with text that exists nowhere else. Write them yourself if you have the time, or brief a model and check a sample by hand. What matters is that on switch day the URL keeps its history and the page stops being a duplicate.

Switch day

The order, once more, because it's where people slip. The old WordPress stays untouched and running. You point the domain at the new site. Redirects answer and the noindex disappears together. Then you watch.

If the domain is changing too, not just the platform, Search Console's Change of Address tool is for exactly that case, and the Google page above explains when it applies and when it doesn't. If you keep the same domain, you don't need it.

Leave the WordPress alone for a while after. If something goes badly wrong in the first days, pointing the domain back is the only real rollback, and it only works if you didn't "clean up" the old install the same afternoon.

The weeks after

Rankings don't jump on switch day. For a while the old URLs keep showing in results as Google recrawls them and follows the redirects. Traffic dips, then settles. Pages whose redirect was right and whose text got rewritten sometimes come back higher than before, since they stopped being duplicates.

In Search Console on the new setup, three things tell you how it's going. Redirect errors, which should stay near empty. The old URLs, which should trend toward "Page with redirect". And the pages that start picking up impressions, usually the ones with new text. If you see a batch of old URLs going to 404 instead, find the pattern behind them in the map before you touch anything else.

How this works on Jimp, briefly

Since this is our forum, the short disclosure. Jimp's WordPress migration does these steps in this order. A plugin sends the posts, every video is checked against its source before it's published, dead ones become redirects to their category, files the WordPress hosted are copied and streamed, the new site stays noindex until your domain is verified, and then every old path answers with a 301. Rewriting the imported text is a separate button, paid in credits, because some owners wrote their own titles and don't want them touched.

But none of the above needs a particular tool. It needs an inventory, a redirect map built from full paths, a noindex you don't forget, and the discipline to touch the old site last. If you're planning a move and want a second pair of eyes on the order, post it here.