Migrating a CMS without losing your SEO

Ten results rank for website migration SEO and every one of them is an SEO agency or an SEO tool vendor. They all publish the same checklist, and the checklist is fine as far as it goes. It stops at the server boundary. “Implement your 301 redirects” is where the article ends and where our job starts.

People ask us how to migrate a website without losing SEO after it has already gone wrong, usually about six days in, when someone finally opens Search Console. In nearly every one of those cases the redirect spreadsheet was complete and correct. The traffic went anyway. Here is what actually took it.

Where you put the 301s matters more than the map

A redirect is not a redirect. On a WordPress site the easy option is a plugin, and a plugin redirect means PHP boots, WordPress loads, the plugin queries a table, and only then does the visitor get a 301. That is 200 to 600ms of server time for a response that should take two. Multiply by a Googlebot crawling forty thousand old URLs and you have quietly turned your migration into a crawl-budget problem.

The same rule in an Nginx map file or an Apache RewriteMap answers in single-digit milliseconds and never touches PHP. It also survives the thing that catches people out six months later: somebody deactivates the redirect plugin while debugging something unrelated, and every one of your old URLs starts returning a 404 with nobody watching.

Chain depth is the other half of it. Old URL redirects to an intermediate URL which redirects to HTTPS which redirects to the trailing-slash version. Each hop is a request. Google follows a handful and then gives up, and your users feel every one of them on mobile. Flatten the chains before launch so every old URL reaches its final destination in exactly one hop. It is a dull hour of work. It is also the hour that decides whether the crawl goes smoothly.

Lower your DNS TTL a week out

Almost nobody does this and it causes more migration damage than any other single mistake we see.

Your DNS records have a time-to-live, and the default on most panels is 3600 seconds or 86400. That number is how long resolvers around the world keep caching your old IP after you change it. Googlebot resolves your domain from its own infrastructure, and it will keep arriving at the old server for as long as its cache says to.

If you have already powered the old box down, or the hosting account is cancelled, those requests hit nothing. Googlebot sees connection failures or a parked page across a large slice of your URL set, during the exact window when it is recrawling everything to discover the move. That is the traffic drop, and it did not come from your redirect map.

Drop the TTL to 300 seconds at least 48 hours before cutover, longer if the current TTL is a day. Then the world picks up the change in five minutes instead of a day. Put it back up to something sane a week after you land.

The staging artefacts that ship to production

This is the most common cause we see, and it is embarrassing every time because it is entirely preventable. Staging sites are built to be invisible to search engines, and then somebody copies the site to production and copies the invisibility with it.

The specific things to check on the live site within ten minutes of cutover:

• robots.txt. If it contains a bare Disallow slash, you have blocked the entire site. This one has taken sites out of the index for weeks.
• The WordPress “Discourage search engines” setting, or its equivalent, which writes a noindex meta tag site-wide from a checkbox nobody remembers ticking.
• X-Robots-Tag headers left in the server config from staging. These do not appear in the page source, so a visual check will not find them. Curl the headers.
• HTTP basic auth. A 401 to Googlebot is a hard stop, and browsers will not show it to you if your credentials are cached.
• Canonical tags and hreflang pointing at the staging hostname. The pages look perfect and every one of them tells Google the real version lives somewhere else.

Two of those are invisible in a browser. Check them with curl or a crawler, from a machine that has never authenticated against the staging site.

Keep the old box warm for 30 days

The instinct after a successful launch is to cancel the old hosting and stop paying twice. Resist it for a month.

The old server is doing two jobs after cutover. It is catching the tail of DNS propagation, which we covered above. It is also your rollback. If something structural surfaces on day four, the ability to point DNS back and think about it calmly is worth far more than thirty dollars of hosting.

Our rule is thirty days, and the old box stays serving redirects rather than the old site. Once you are confident the move is stable, replace the old document root with a redirect rule to the new host and leave it running. Cheap insurance. We keep this in scope on every job that goes through the Migration Pack, and it is one of the reasons the price is fixed at $450 rather than quoted by the hour.

What a normal dip looks like

Nobody tells you this, so people panic at the wrong moment and cause the damage they were trying to avoid.

Every migration loses something for a while. Google has to recrawl the old URLs, follow the redirects, reassess the new ones and reassign the signals it had attached to the old addresses. That takes weeks, not hours, and there is no way to make it instant. A same-domain platform move with clean single-hop redirects usually wobbles ten to twenty five percent for two to four weeks and is back to baseline inside two months. A domain change takes longer and dips deeper, because the trust attached to the old hostname has to move across too.

What that means in practice is that day three tells you nothing. Day three always looks bad. The number worth reacting to is the shape of the curve at two weeks: if you are still down sixty percent then, that is not a dip, that is a fault, and it will be visible in the logs rather than in the analytics.

So the discipline for the first fortnight is to change nothing except outright errors. Fix 404s, fix broken redirects, fix a page that fails to render. Do not redesign the navigation, do not consolidate URLs you always meant to consolidate, do not roll out the new content plan. Every structural change restarts the recrawl and adds a fresh variable, and after three of them nobody can tell you which one caused what.

Read the access log, not Search Console

Search Console is where everyone looks on launch day and it is the wrong instrument. The data lags by two to three days, the coverage report lags longer, and by the time a problem shows up there it has been happening for most of a week.

The access log tells you the truth within the hour. On the new server, filter for Googlebot and look at the status codes it is receiving. You want to see 301s on the old paths and 200s on the new ones. If you see 404s, your map has holes. If you see 500s, something in the new stack is falling over under crawl load specifically, which is a common surprise when the old host had object caching configured and the new one does not yet.

Then do the same on the old server. Googlebot should still be arriving there for a few days and should be receiving 301s. If it is receiving anything else, you have a DNS or a redirect problem and you have found it four days early.

Verifying from logs is the part of this job that needs shell access, which is why it usually falls off an SEO-led migration and why we treat it as part of hosting support rather than an SEO deliverable.

How to migrate a website without losing SEO, in order

The order below matters more than any individual step in it.

1. Crawl the current site and export every URL that returns a 200. Not the sitemap. The sitemap lies.
2. Pull the top 200 URLs by organic landing sessions and mark them. These are the ones that must not break, and they get checked by hand later.
3. Build the map, then flatten it so no entry needs two hops.
4. Drop the DNS TTL to 300.
5. Build the new site and put the redirect rules in the web server config, not in a plugin.
6. Strip the staging artefacts. Curl the headers to confirm.
7. Cut over during your quietest traffic hour, which is not necessarily the middle of the night in your own timezone.
8. Submit the new sitemap, and use the Change of Address tool in Search Console if the domain itself changed. Google’s own site move documentation is worth ten minutes here.
9. Watch the access logs on both boxes for 72 hours.
10. Hand-check the marked top 200 on day three.
11. Keep the old server alive for thirty days.

Steps four, five and eleven are the ones that separate a clean move from a bad quarter, and they are also the three that no SEO checklist includes, because all three of them need root on a server.

What it costs and who should do it

A single site with a normal plugin set and one database is a $450 fixed price job for us, three to five business days, most of it waiting rather than working. Big stores, multisite installs and anything on a custom server stack get looked at first and quoted after. We would rather look than guess.

If you have an SEO agency, keep them. This is not a competing service. They should own the redirect map and the benchmarking, because that is their craft and they are better at it than we are. What they should not be doing is editing Nginx config through a hosting panel at 11pm. Split the work along that line and migrations stop being frightening.

We have written up the platform-specific versions of this for people already mid-move: moving a WordPress site, going from shared hosting to a VPS, and getting off WP Engine without the lock-in surprises. If a move has already gone wrong and traffic is gone, that is a recovery job and the first thing we ask for is the access log.