Key takeaways
- Export the old site's redirect rules before you switch anything. A crawl finds the URLs you can see. The export finds the ones that were already being redirected years ago and still carry links.
- A missing redirect on a modern site usually is not a 404. It is a page that answers
200with a "not found" message, so Google is never told the page is gone. - Google uses a permanent redirect as a signal for which URL should be canonical, and explicitly does not use a temporary one that way. The status code is a ranking decision, not a plumbing detail.
- Retired URLs keep reporting for months after a correct move. Six weeks after ours, one retired URL was still drawing 7,468 impressions a quarter.
- Check the HTML a crawler receives, not the page your browser shows. On a JavaScript-rendered rebuild those two stopped being the same thing.
Most migration advice is a list of tasks with no dependencies between them, which is the one thing a migration actually has. If the redirects are wrong, nothing downstream matters. If the new pages answer correctly but render empty to a crawler, the redirects were wasted. The order is the method.
ByteZero moved this site off WordPress in July 2026. What follows is the sequence we used, the two things we got wrong, and what Google's own documentation says will happen afterwards — which is less dramatic and slower than the folklore suggests.
Export the old redirect rules, do not reconstruct them
The redirect map is the whole migration. Everything else is recoverable in an afternoon.
There are two ways to build one. You can crawl the old site and map every URL you find to its new home. Or you can export the rules the old site is already running — the WordPress Redirection plugin, the .htaccess block, the CDN rule set — and carry those across as well.
The second matters more than it sounds, because a site that has been live for years is already redirecting URLs that no longer appear anywhere in its own navigation. Those URLs still have links pointing at them. A crawl of the current site will never surface them.
We did the first and not the second. The comment sitting in our redirect file still says so:
"this list was built by probing known/likely URLs, not exported from the WP Redirection plugin (its REST API needs an admin credential). Before DNS cutover, export Redirection's full rule set and reconcile — there may be rules here we never guessed."
The credential arrived after the cutover, not before. If you are planning a move, get read access to the redirect plugin earlier than you think you need it. It is the one artifact that cannot be reconstructed from the outside.
Choose the redirect type deliberately
Google's redirect documentation is unusually blunt about what each type does. For a permanent redirect, "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." For a temporary one, "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical."
That is the entire difference, and it is the difference between the new URL inheriting the old one's standing and the old URL staying the one Google prefers. A migration served over 302s is a migration that has not happened yet.
| Method | What the server returns | How Google treats it | Use it for |
|---|---|---|---|
| Server-side permanent | 301 or 308 | Signal that the target should be canonical | Every URL in a migration. This is the default. |
| Server-side temporary | 302 or 307 | Not a canonicalisation signal | Genuinely temporary detours — maintenance, A/B tests. |
meta refresh | 200, then a client-side hop | Followed, but slower and weaker than a server redirect | Only when you cannot change server configuration. |
| JavaScript | 200, then a script-driven hop | Depends on rendering succeeding | Last resort. Google's guidance: "Only use JavaScript redirects if you can't do server-side or meta refresh redirects." |
Google ranks these by "how likely Google is able to interpret correctly (for example, a server side redirect has the highest chance of being interpreted correctly by Google)." If you can reach the server or the CDN, that is where the redirect belongs.
The missing redirect that does not look missing
We missed one URL. It was not the miss that cost us — one URL out of a few hundred is a decent hit rate. It was how the miss presented.
An old post comparing Google Ads to Bing Ads had been consolidated into a newer comparison during the rebuild, and no redirect was written for it. On a classic server that produces a 404, which shows up in Search Console within days and gets fixed. On this stack it produced something worse: the request landed on the site's not-found page, and that page answered 200 OK. The URL was still drawing roughly 189 impressions a quarter, every one of them arriving at a page that told the visitor nothing was there and told Google everything was fine.
Single-page applications and edge-rendered sites do this by default, because the router answers every path before it knows whether the path exists. Before you migrate, request a deliberately fake URL on the new build and read the status code. If it is 200, you have no error signal at all, and every missed redirect will hide from you indefinitely.
What Google says happens next, and how long it takes
The timeline in most migration write-ups is invented. Google's is documented, in its guide to site moves with URL changes.
On sequencing: "Small or medium sites: We recommend moving all URLs on your site simultaneously," with section-by-section moves reserved for large sites. On pace: "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs." On what you should brace for: "Expect temporary fluctuation in site ranking during the move."
And on the question everyone gets wrong, which is when the redirects can come down:
"Keep the redirects for as long as possible, generally at least 1 year." — Google Search Central, Site moves with URL changes
A year. Not a sprint, not until the new URLs appear. The redirect map is a permanent fixture of the site, and treating it as temporary scaffolding is how a migration that went well in August becomes a traffic drop in February.
Worth knowing before you open Search Console looking for a button: the Change of Address tool is narrower than its name. Google states "You only need this tool when moving from one domain or subdomain to another," and that "You don't need it for HTTP to HTTPS moves, switching between www and non-www." A platform change on the same domain does not use it.
The old URLs stay in your reports for months
This is the part that generates the most unnecessary panic, so here is what it looks like on a move that went correctly.
Six weeks after our cutover, the retired URL for an old San Francisco lawyer page was still recording 7,468 impressions at an average position of 55.5 over a 90-day window. It has returned a permanent redirect to its replacement since the day of the move. Another retired landing page recorded 1,044 impressions at position 21.6, also correctly redirected from day one.
The same effect shows up on URL variants. Our trailing-slash form redirects to the canonical form, and Search Console still reports both as separate rows: 2,187 impressions at position 35.0 for one, 3,126 impressions at position 21.8 for the other. Same page, two rows, one of them a URL that has not served content in weeks.
None of that is a fault. Google's crawl budget documentation explains the mechanism plainly — "URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems" — which means a low-traffic retired URL is exactly the kind Googlebot revisits slowly. Your migration finishes at crawl rate, not at deploy time. Google's own description of the sitemap side is the same shape: the old sitemap's indexed count "would drop to zero" over time, rather than at once.
What would be a fault is the new URL not appearing at all after several weeks, or impressions moving to the redirect target while clicks disappear. Those are worth investigating. Two rows for one page is not.
Check what the crawler receives, not what your browser shows
Our second mistake was the more dangerous one, because nothing about it was visible.
The rebuilt site carried its titles, descriptions, canonical tags and structured data correctly — in the browser. They were being written by JavaScript after the page loaded. Opened in Chrome, every page looked right. Fetched as raw HTML, the head was close to empty. We found it and fixed it on 17 July 2026, but a browser check would never have found it, because a browser runs the JavaScript.
The check takes one command and belongs in the migration itself, not the follow-up audit: request the page with a plain HTTP client and read what comes back before any script runs. If the title, the canonical and the JSON-LD are not in that response, an assistant summarising your page and a crawler indexing it are both working from a blank document. We wrote up the wider version of this — how to run a site analysis in dependency order — after the same class of problem turned up at the edge rather than in the markup.
The migration checklist, in dependency order
Each step is only worth doing if the one above it passed.
| # | Step | How you know it passed |
|---|---|---|
| 1 | Export the old platform's redirect rules and reconcile them against a full crawl | Two lists, merged, with the difference explained rather than dropped |
| 2 | Decide what does not come across | Thin or duplicated pages redirect to a real destination, not to the homepage |
| 3 | Confirm the new build returns a real error for an unknown path | A fake URL returns 404, not 200 |
| 4 | Serve every mapped URL as a server-side permanent redirect, one hop | curl -I shows a single 301 straight to the final URL |
| 5 | Verify head tags and structured data in the raw HTML response | Title, canonical and JSON-LD present before any script executes |
| 6 | Publish the new sitemap and keep the old one live for a while | New URLs listed; old sitemap's indexed count falling toward zero |
| 7 | Watch server response times and error rates through the move | No sustained 5xx or latency rise — Google crawls less when it sees them |
| 8 | Leave the redirects alone for at least a year | Nobody "cleans up" the redirect file in Q4 |
Step 7 is the one that gets skipped, and Google is specific about the consequence: "If the site slows down (latency increases or response times become longer), or responds with server errors (5xx HTTP status codes) or rate-limiting signals (such as HTTP 429), the limit goes down and Google crawls less." A migration is the moment you most need Google crawling more. A slow or flaky launch week extends the move by weeks you cannot see.
Consolidate during the move, not after it
A migration is the cheapest opportunity you will ever get to delete pages, because you are rewriting every URL anyway.
Our old site carried twenty-two near-identical city pages for the same legal service, differing by place name. They earned almost nothing and they diluted the page that should have been earning. Rather than porting them, we redirected all of them into a single law firm website design destination and one vertical hub. Doing that as part of the move cost nothing extra. Doing it six months later would have meant a second round of redirects on URLs Google had just finished re-learning.
If a set of pages would not survive an honest review, the move is when they go.
Frequently asked questions
How long does a website migration take to recover in Google?
Google's own guidance is that "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs," and it tells site owners to "expect temporary fluctuation in site ranking during the move." Weeks is normal. The pace is set by how often Googlebot recrawls your old URLs, which is slower for pages that were not getting much traffic to begin with.
Should I use 301 or 302 redirects for a site migration?
301. Google uses a permanent redirect "as a signal that the redirect target should be canonical" and states that a temporary redirect is not used that way. A migration served over 302s leaves the old URLs as the ones Google prefers, which is the opposite of the intent.
Why are my old URLs still showing in Search Console after the migration?
Because Google has not recrawled them yet, and it will not do so quickly for low-traffic URLs. Six weeks after our own move, one correctly redirected URL was still reporting 7,468 impressions over a 90-day window. Two rows for the same page — one old URL, one new — is expected reporting residue, not a broken redirect.
Do I need the Change of Address tool in Search Console?
Only for a domain or subdomain change. Google states "You only need this tool when moving from one domain or subdomain to another" and that "You don't need it for HTTP to HTTPS moves, switching between www and non-www." Replatforming on the same domain does not use it.
How long should redirects stay in place after a migration?
"Keep the redirects for as long as possible, generally at least 1 year," in Google's words. Treat the redirect map as a permanent part of the site. Removing it once traffic looks recovered is how a successful migration turns into a delayed loss.
What is a soft 404 and why does it matter during a migration?
A soft 404 is a missing page that returns 200 OK instead of an error. Single-page and edge-rendered sites produce them by default, because the router answers before it knows the path exists. It matters because Google is never told the page is gone, so the URL sits in the index drawing impressions to a dead end and never appears in your error reports.
Should I redesign and migrate at the same time?
You can, and there is a real argument for it — you are rewriting every URL anyway, so consolidation is nearly free. The cost is diagnostic: if traffic moves, you will not know whether the cause was the URLs, the content, or the design. Keep the redirect work and the content work in separate commits so you can tell them apart afterwards.
Where migrations actually go wrong
Not in the redirect file. In the assumption that a page which looks right is right. The two failures on our own move were a URL that returned success while serving nothing, and a set of head tags that existed in the browser and nowhere else. Both were invisible to a person clicking around the new site, and both took one command to catch.
If you are planning a replatform and want the redirect map and the crawler-side checks handled properly, that is part of how we build sites, and the results are in our client work.
