After the Move: What to Watch in the First Thirty Days

The site is live on the new platform and the domain has settled. This is the point at which most migration guides stop, and it is the point at which the thing you were actually worried about — traffic — starts to move.

Some movement is unavoidable. Search engines have to re-crawl a site that has changed every one of its addresses, and until they do, their picture of you is out of date. What matters is whether the movement has a floor and a recovery, and that is mostly determined by work you either did or did not do before launch.

Day one: the checks that cannot wait

Before you do anything analytical, confirm the site works. In this order, because each one is a different failure.

• Load the home page from a device that has never visited the new site. Mobile data on a phone is the easiest clean test.
• Check that the padlock is there. Certificates are usually issued automatically within minutes to hours of the domain resolving to the new platform; a warning on day two means the platform has not finished its side and needs chasing.
• Submit every form and confirm the notification arrives in an inbox a human reads.
• Send an email to your domain from an outside address, and reply to it from the mailbox.
• If you sell anything, place a real order with a real card, take the confirmation email, then refund it.
• Confirm analytics is recording sessions. A tag that did not survive the rebuild costs you the ability to diagnose anything else.

Only when all six are true is it worth looking at anything else.

Week one: redirects, sitemap, errors

Sample the redirect map. Take twenty rows at random — the odd ones, not the obvious ones — and visit each old URL. Each must land on the intended page, arrive by a 301 rather than a 302, and get there in one hop rather than through a chain. Open the developer tools, watch the request, and read the status code off it.

Submit the new sitemap. Check first that it lists what you expect and does not list pages that no longer exist. A sitemap full of URLs that redirect is a sitemap that has not been regenerated.

Read the error report daily. Every 404 is a URL missing from your map. Each one takes two minutes to fix while the move is fresh in your mind and considerably longer in three months when you have forgotten what the old structure was.

Check your internal links. If content was imported, its internal links probably still point at the old URL structure. They will work, because your redirects catch them, but every internal link then depends on a redirect — which is slow, fragile, and a thing to fix rather than tolerate. Find and replace them properly.

Change of address, only if the domain changed

This tool is for one specific situation and gets reached for in several others.

Google’s Change of Address tool applies when you move between domains or subdomains — from one name to a different name. It tells Google about the change and forwards signals from the old site for a period, documented as 180 days. To use it you need to be an owner of both the old and the new properties in Search Console.

Two limits worth knowing before you go looking for it. It works only on properties at the domain level, and it does not move subdomains for you — a subdomain being migrated somewhere different needs its own property and its own separate move.

And the case that matters most here: if you changed platform but kept the same domain, this tool is not for you. Google’s own guidance excludes hosting changes that do not change your URLs, and a same-domain platform move is handled entirely by your redirects. There is nothing to submit and nothing to wait for.

What a normal dip looks like

Expect positions to move. Search engines re-crawl at their own pace, and a site whose every URL has just changed gets re-evaluated address by address rather than all at once. Big archives take longer than small ones simply because there is more to crawl.

The shape of a normal recovery is a dip, a wobble, and a return toward where you were. It does not happen in a day and it is not linear.

Two things that will make you panic unnecessarily. Impressions and positions often move before clicks do, so the reports look worse than the reality for a while. And a brand-new set of URLs has no history, so early data on them is thin and noisy. Resist the urge to change anything in the first fortnight based on a graph.

When a dip is actually a broken migration

There are specific signatures worth checking before you conclude the move itself was the problem.

Missing content. Open your five most important pages and read them against your screenshots of the old site. Truncated imports are a far more common cause of lost position than anything algorithmic, and they are invisible unless you look.

Redirects that are not 301s. A 302 tells a search engine the move is temporary and that the old address should be kept. An entire site redirected with 302s behaves exactly like a site that has lost its history.

Redirect chains. Old URL to intermediate URL to final URL. Each hop dilutes and slows. Flatten them so every old address points straight at its destination.

Missing page titles and descriptions. Most exports do not carry them, so most migrations lose them unless somebody re-entered them. A hundred pages sharing one title is a self-inflicted wound.

Blocked crawling. Check the new site is not still carrying the “discourage search engines” setting or a password from the build phase. This one is embarrassingly common and completely invisible from the front end.

Images loading from the old platform. If your new pages are fetching media from the old host, they will break the day you cancel it. Fix before, not after.

Month one: a fair comparison

At the thirty-day mark, compare like for like. Not this month against last month — this month against the same month last year, and this month against the four weeks before the move, with the move date annotated in your analytics.

Compare at page level rather than site level. Site totals hide the interesting thing, which is almost always that a few specific pages fell while the rest were fine. Those pages are where the fault is, and the fault is usually a redirect, a truncation or a missing title rather than anything mysterious.

The long tail, and the note for next time

Forgotten URLs surface slowly. Something you have not thought about in two years gets clicked in November and turns up in your error report. Keep checking it monthly for a while; the fixes stay cheap.

Then write two things down while you still remember them. What broke, so that the next move does not repeat it. And what your URL structure now is, so that the next person to touch this site — possibly you, in four years — starts with a map rather than an archaeology project.

The order everything above sits in is on the plan for switching website builders, and the verification list is in the moving-day checklist.