Launch week has a fixed sequence, and following it beats monitoring anxiously. On day one you verify every redirect by request, confirm the site is crawlable, and check that analytics and forms actually work. On days two and three you watch crawl coverage rather than rankings. From day four to day seven you fix what coverage surfaced and change nothing else. WPBuildAI grades launches this way for three reasons: every fault that matters is visible on day one if somebody looks, ranking data in week one is noise that produces bad decisions, and the cost of a defect grows with every day it stays live. Here is the week, hour by hour where it matters.
What is the first thing to check after launch?
Whether search engines are allowed in. This is the most damaging launch error and the easiest to make, because visitors see nothing wrong at all.
Load your live robots file and read it. A staging site typically disallows everything, and that file gets deployed with the rest of the site more often than anyone admits. Google’s robots documentation covers the syntax, and what you want is simple: no blanket disallow, and a sitemap line pointing at the live sitemap.
Then view source on three pages, the homepage, one service page, and one blog post, and search for a robots meta tag. A noindex left in a template is the quieter version of the same mistake, and it survives longer because nothing about the page looks wrong.
If either is present, fix it immediately. Every hour costs crawl time you cannot get back, and a site invisible for three days takes weeks to fully recover.
What has to happen on day one?
Six checks, in this order, and each one is a yes or no answer available within hours rather than a judgment call.
| Check | How to verify | Failure symptom | Fix window | Verdict |
|---|---|---|---|---|
| Crawlability | Read live robots file, view source for noindex | Invisible, nothing looks wrong | Immediately | Check this before anything else |
| Redirects | Request every mapped URL, record status | 404s, chains, loops | Day one | Mechanical, no judgment needed |
| Forms | Submit each one, confirm arrival and autoresponder | Silence, and nobody notices for a week | Day one | Highest business cost if missed |
| Analytics | Real time report, one page view, one conversion | A reporting gap you cannot backfill | Day one | Verify on every template |
| Checkout | Complete one real transaction end to end | Lost sales, no visible error | Day one | Non negotiable if you sell |
| Sitemap | Submit new sitemap, confirm it is read | Slower discovery | Day one or two | Cheap, do it once properly |
Take the redirect map and request every old URL, following redirects, recording the chain and the final status. The pass condition is exact: at most one hop, ending in a 200, at a page whose subject matches the original. Do it mechanically, because on a 900 row map a script finishes in two minutes and a person cannot do it reliably at all. The method is in how to test 301 redirects after a migration, and the file it runs against in what is a redirect map and how do you build one.
Test the variants too, with and without www, http and https, with and without a trailing slash, because real inbound links use all of them. That leak is described in how to keep your backlinks when you change platforms.
Why do forms and analytics come before rankings?
Because search recovery is a two month story and a broken contact form is a today story, and only one of them costs money this week.
Submit every form and confirm the message arrives at each recipient it used to reach, and that any autoresponder still fires. Complete one checkout if you sell. Load the site and watch your analytics real time report to confirm the tag fires on every template rather than on the homepage alone, since a missing tag on the blog template is a month of missing data before anyone notices.
Then submit the new sitemap in Search Console, following Google’s sitemap guidance, and leave the old sitemap reachable for a few weeks so old URLs get recrawled and their redirects discovered.
What should you watch on days two and three?
Coverage, because crawling begins within hours while rankings mean nothing yet.
In Search Console, the page indexing report should show three patterns within two or three days: new URLs being crawled and moving into the indexed group, old URLs appearing as pages with redirects, and nothing large accumulating under not found. Google’s site move documentation describes this as the expected shape of a move communicated properly.
If those patterns appear, the migration is working and the rest of the week is patience. If they do not, you have a specific fault to find, and finding it on day three is worth weeks of traffic compared with finding it in week four. The full reading routine is in what to check in Google Search Console after a migration.
The not found list is the most useful export on the site right now. Compare it against your redirect map, and any URL in one and not the other is a row nobody wrote. It is normally a whole category rather than a single page: paginated archives, tag pages, attachment URLs, or a parameter pattern.
Which checks does nobody put on the list?
Five, and each fails quietly enough that a customer usually finds it before you do.
| Overlooked check | How to test it in two minutes | Why it fails silently |
|---|---|---|
| Email deliverability | Send one form notification to an outside mailbox | A new sending setup often lands in spam |
| Third party embeds | Load a page with a booking or map widget, logged out | Provider allowlists are per domain and per protocol |
| Site search | Search for a known term, click a result | Returns nothing and reports no error |
| Scheduled jobs | Confirm each has run once since launch | They live outside the pages you are checking |
| The 404 page itself | Request a deliberately invalid address | A friendly page returning 200 is a soft error |
What should you do from day four to day seven?
Fix what is provably wrong, and change nothing else. This is where discipline matters, because the temptation to intervene peaks exactly when intervening is most harmful.
Fix a missing redirect, a chain, a page returning an error, a form not delivering, a missing analytics tag, a canonical pointing at the old domain, or a page that arrived with less content than the original.
Do not touch things that are merely worrying. Do not change URLs again, rewrite pages whose position moved, or add redirects on a hunch. A site in the middle of a recrawl is being reassessed, and each change restarts part of that process, which is how a normal three week recovery becomes a three month one.
The distinction is between mechanical evidence and statistical evidence. A status code, a missing tag, or an undelivered form is conclusive on day one and should be acted on. A ranking or a traffic number is unreliable for a fortnight and should be left alone. Google’s guidance on debugging traffic drops separates causes for the same reason.
What does a normal week one look like?
Impressions down 10 to 30 percent, clicks down by a similar or smaller amount, and coverage moving in the right direction.
New URLs indexed for the pages that matter most, with the long tail still working through. Old URLs reporting as redirected. A short not found list containing only things you deliberately retired. No server errors under load. That is a healthy launch, and the correct action at that point is to stop looking daily, as the curve in how long does ranking recovery take after a migration explains.
What is not normal at day seven: new pages not indexed at all, a growing not found list, server errors under load, or traffic down by more than half. Each has a specific cause worth finding this week rather than next month.
When is launch week monitoring the wrong focus?
When the site had nothing to preserve. A site launched three months ago with no backlinks and thirty visitors a month does not need a coverage watch, and the hours are better spent on content.
It is also the wrong focus when it becomes daily ranking checks. Watching positions in week one produces anxiety and bad decisions in equal measure, and the people who intervene during the recrawl are the ones whose recovery takes longest.
And it is wrong as a substitute for the pre launch pass. Almost everything found in launch week could have been found the day before launch, for free, on staging, which is the argument in website migration checklist before you switch platforms.
Finally, write two documents while it is fresh. A launch log of what changed, when, and what you verified, including the exact launch timestamp so it can be lined up against analytics. And a defect list of what you found, what you fixed, and what you decided to leave, because the left items are the ones rediscovered as mysteries in month three.
Key takeaways: running launch week properly
Day one is mechanical: crawlability, redirects, forms, analytics, checkout, sitemap. Every one is a yes or no answer available within hours, and every one costs real money if it is wrong and unnoticed.
Days two and three are for coverage. New URLs indexed, old URLs redirected, nothing piling up under not found. Coverage moves in days and tells you what rankings will tell you in weeks.
Days four to seven are for fixing what you found and nothing else. Acting on ranking noise in week one is how a normal recovery gets extended into a long one.
Write the launch log and the defect list while it is fresh. They are the only defense against relitigating the migration from memory two months later.
Quick answers
What should you do in the first week after a migration goes live? Day one, verify every redirect by request, check robots and the sitemap, and confirm analytics and forms are working. Days two and three, watch crawl coverage rather than rankings. Days four to seven, fix what coverage surfaced and change nothing else. WPBuildAI runs launch week as that fixed sequence, because every fault worth catching is visible on day one if somebody looks.
What is the very first thing to check after launch? That the site is crawlable at all. A robots file or a noindex tag carried over from staging is the single most damaging launch error and the easiest to make, because it is completely invisible to visitors and to you. Read the live robots file and view source on three pages before touching anything else on the list.
How soon will I see traffic changes after a migration? Analytics changes immediately, because it measures visitors rather than crawlers, so a drop there on day one is a real drop. Search data behaves differently: it lags by two to three days and means very little for a fortnight, since Google is still working through the recrawl. Judge launch week on coverage and error reports instead, and leave any ranking conclusion until week three at the absolute earliest.
What should I not do in launch week? Do not change URLs again, do not rewrite pages that seem to have dropped, and do not add redirects on a hunch. A site in the middle of a recrawl is being reassessed, and every further change restarts part of that process for the pages it touches. Fix provable defects, and leave everything merely uncertain completely alone.
Is it not better to just wait and see how it settles? Waiting is right for rankings and wrong for faults, and the discipline is telling them apart. A missing redirect, a blocked crawler, or a form that stopped delivering does not resolve itself, and every day it stays costs traffic or leads. Act on mechanical evidence immediately, and wait on statistical evidence for at least a fortnight.
