- Home
- About
- Service
- News & Insight
- Contact
- Resources
Innovative Thinking
-
Innovative Case
-
Every website launch checklist runs to about twenty items, presented as equals: favicon, contact form, image sizes, SSL, spelling. They are not equals. Most, if missed, cost an awkward Monday morning. A few cost something that does not come back.
This article is about that second group. Four checks, in the order they bite, with what Google’s own documentation says about each. If you run nothing else before going live, run these.
Four. Every old address must answer with a redirect to its replacement. The noindex instruction that kept the staging copy out of search must be gone from the live copy. Measurement must be collecting from the first visit. And the sitemap must be submitted so the new structure is found quickly rather than eventually.
What they have in common is time. A missing favicon is the same problem on Tuesday as on Friday. A missing redirect is worse every day: each day an old URL returns a 404, its rankings decay a little more, and visitors who bookmarked it meet a dead end. Google’s guidance for a site move with URL changes also rules out the lazy fix: don’t redirect many old URLs to one irrelevant single URL destination, such as the home page. Each old page points at its real equivalent, or at nothing.
A missing favicon is the same problem on Tuesday. A missing redirect is a worse problem every day.
The full redirect method is in redesigning a website without losing SEO, and the hosting side of a move in migrating a website without breaking it. What follows assumes the map exists and is about checking it is live.


Because the live site is usually the staging site, copied. A development copy is correctly hidden from search while it is being built, and the common way to hide it is a noindex rule. Google’s page on blocking search indexing with noindex describes it as a rule set with a <meta> tag or an HTTP response header to prevent indexing. It does exactly what it says. The failure is not that it works; it is that it travels.
When the build is copied to the live domain, that tag comes with it unless someone removes it. The site looks perfect to anyone who types the address. Google, following the instruction, begins removing the pages from its index — and nothing on the page tells you, so it is routinely discovered weeks later by someone wondering where the traffic went.
The check takes thirty seconds: view the source of the live home page and one inner page and search for noindex, then check the response headers, where the rule can be sent instead. On WordPress the usual culprit is one checkbox under Settings → Reading ticked on staging. Untick it on the live site, not only on the copy you built.

Only that the analytics tag is on the live pages before the first real visitor arrives, because data never collected cannot be recovered. Google’s setup guide for Analytics is plain about the sequence: to begin seeing data in a new property, you add the tag to the website, by a CMS integration or directly, and only then does anything appear.
This belongs among the four because launch week is the week you will most want to look back on: when you learn whether the new structure is being found, which pages people land on, and whether the enquiry path works under real use. A site that goes live on the first and gets its tag on the eighth has no record of the week that mattered most. What to switch on inside the setup is its own article; here it matters only that the tag is firing on the live domain before launch, which the realtime report confirms from your own phone.
One linked check belongs with it: confirm the enquiry form delivers to a real inbox on the live domain, not the developer’s — what to have in place before a website goes down covers why that fails quietly.
Less than people think, and more than zero on launch day. Google’s documentation on building and submitting a sitemap positions it as a way to help search engines find and understand the URLs on your site, and submitting it through Search Console takes a minute. On an established, well-linked site it changes little; on one that has just replaced every URL, it is the fastest way to say so.
Which is why the step is worth doing in Search Console rather than trusting the plugin that generates the file: submitting it there gives you the one report showing, over the following week, which new URLs Google has found and which it has not. That is the launch-week monitoring. Read it daily for seven days, then weekly. Pages that fail to appear usually trace back to the first two checks — a redirect pointing at the wrong place, or a stray noindex.
If the old site carried pages that should not come across at all, launch is the right moment to let them go cleanly rather than redirect them to the home page; which pages to remove and what to do with listings that have sold cover the two common cases.
| Day | Do | You are protecting |
|---|---|---|
| Before launch | Finish the redirect map; confirm the analytics tag fires on the live domain | Rankings; the record of week one |
| Launch morning | Switch DNS; immediately search the live source for noindex; check robots.txt | Indexing |
| Within the hour | Submit the sitemap in Search Console; send a test enquiry from a phone | Discovery; the enquiry path |
| Days 1–7 | Read the Search Console page report daily; fix any 404s the old URLs produce | Everything above |
One piece of advice is ours rather than Google’s: we do not launch on a Friday. Nothing technical changes at the weekend, but the first forty-eight hours are when the problems above show themselves, and they are cheaper to fix with the people who built the site still at their desks. A Tuesday launch gives you three working days of attention. That is also the thinking behind revamping a website without downtime — the aim is a launch nobody notices.
None of this replaces the longer list; it sits in front of it. Once the four are confirmed, work through the twenty in order of annoyance — the full revamp checklist and what to keep from the old site hold that list.
Recoverable. Remove the rule from the live pages, confirm the live source no longer carries it, and request indexing for the key pages in Search Console. Google re-crawls and reinstates pages over days and weeks; nobody can promise a date. The lost week is a one-off cost.
If every URL is genuinely identical there is nothing to map, and the risk moves to the noindex check and the pages you quietly dropped. Crawl the old site before launch and the new one after: pages in the first and absent from the second are your redirect map, however short.
The agency does the work; you hold the list. Ask for the redirect map as a file before launch, to see the analytics realtime report on the live domain, and for the Search Console submission to be made in a property you own. Those three requests make the launch checkable by someone who did not build it.
Every launch we run goes out behind this short list before the long one, because the cosmetic problems live in the long list and the expensive ones in the short. Our web development and design service includes the redirect map as a readable deliverable, the measurement check on the live domain, and a week of Search Console monitoring after the switch. If a launch is already behind you and the rankings have not followed, the four checks above are still the first things to look at.