Skip to main content

WEBSITE RELAUNCH · CHECKLIST

Website relaunch checklist: twelve steps to go-live

Twelve steps, in the order they are done. The first three belong at the start of the project rather than the end: the address inventory is what the new site is drawn against, and a redirect map retrofitted to a finished structure easily stays incomplete.

  1. Export every address the old site has

    Pull the full URL list from the sitemap, the server logs, Search Console and a crawl, because no single one of those four is complete. This list is the document the entire relaunch is checked against, and everything below refers back to it.

  2. Note what each address is worth

    Add impressions, clicks and inbound links to every URL on the list. Without this, the decision about which pages to merge or drop is guesswork, and the page quietly dropped can easily be one that brings in many visitors.

  3. Map every old address to a new one

    Each URL gets a destination on the new site, and the ones with no obvious counterpart get a decision rather than a default. A redirect to the homepage is treated as a page being given up, because search engines can treat it like a missing page.

  4. Move the content that earns the positions first

    A page ranks because it answers something at a certain depth, so the new version needs to answer it at least as fully. Shortening a well-ranking page during the redesign can cost the position it holds.

  5. Carry titles and descriptions across deliberately

    A page that ranks well has a title Google has been showing for a long time, and rewriting all of them in the same week makes it impossible to attribute any later movement. Change the ones that are genuinely wrong and leave the rest alone until after the launch has settled.

  6. Check the structured data on the new pages

    Rich results disappear when the markup describing them does not survive the move, so every page that had a breadcrumb trail, product data or event data needs the same node afterwards. Validating it before the switch is cheaper than noticing the lost rich result weeks later.

  7. Remove the staging noindex, then check it twice

    A staging environment is normally kept out of the index with a noindex header or closed to crawlers in robots.txt. If the noindex travels to production, search engines drop the site from their results page by page as they recrawl it. If the robots.txt block travels, they can no longer crawl the pages at all, and the pages appear, if at all, without a description. From the outside it looks like a penalty, and in the browser nothing shows.

  8. Verify canonicals point at the new site

    A canonical tag left pointing at the old domain or at a staging host tells search engines the page they are looking at is not the real one. This survives a redirect check unnoticed, because the page loads correctly and only the tag inside it is wrong.

  9. Carry images, PDFs and downloads across

    Documents and images have their own addresses, get linked from other sites, and can appear in image search. They are also easy to forget in a migration, because a page inventory built from HTML pages does not list them.

  10. Rebuild analytics and its conversion goals

    A new site means new page paths, and every goal, funnel and event defined against the old paths stops recording on the day of the switch. Rebuilding them before go-live is what makes the weeks after the relaunch comparable with the weeks before it.

  11. Test on real devices and real connections

    Check the new site on iOS and Android, in Safari, Chrome and Firefox, and on a throttled connection rather than office wifi. Forms are worth submitting for real on each, since a contact form that silently fails is otherwise only noticed when enquiries stop coming in.

  12. Switch at an agreed time, then watch and change nothing

    Lower the DNS time-to-live in advance, switch at a time somebody is available to react, then submit the new sitemap and watch crawl errors and positions over the following weeks. Any change made in that time becomes impossible to tell apart from the relaunch itself.

Questions about the checklist

Which mistakes should a website relaunch avoid?

Two weigh especially heavily, and both can be prevented before go-live. Old addresses that lead nowhere after the switch, which loses the positions those pages held, and a staging noindex or robots.txt block that travels to production: a noindex takes the pages out of search results as they are recrawled, and a robots.txt block stops search engines crawling them at all. The second is hard to spot, because it is invisible in a browser and looks like a penalty from the outside.

How long before go-live should the checklist be started?

The first three points belong at the very beginning of the project, not at the end, because the address inventory is what the new sitemap is drawn against. Starting the redirect map after the new site is built means retrofitting it to a structure that was decided without it, and that is how redirect maps end up incomplete.

Do we need to redirect every single old URL?

Every URL that has value needs a decision, which is not the same as a redirect. A page with traffic or inbound links gets a redirect to its real counterpart. A page with neither, such as an old campaign address nobody links to, can be allowed to return a not-found status. That is an honest signal and it is better than redirecting it somewhere irrelevant.

How long does a website take to recover after a relaunch?

That cannot be said in advance. Search engines have to recrawl the site and reassign the redirected addresses, and larger sites take longer simply because there is more to recrawl. Movement in the first weeks is normal and is not on its own a reason to change anything. Reacting to it is how a recoverable dip becomes a permanent one.

Straight to the owner

Your new website: fixed price, built personally by the developer

A website for trades, practices and service providers that loads quickly, looks good on every phone and keeps the path to an enquiry short. Tell me in one sentence what you need, and I will get back to you in person.

  1. 01

    Send a quick request

    Name, phone or e-mail, one sentence. That is all.

  2. 02

    Free first call

    What should the site achieve, who are your customers, what exists already?

  3. 03

    Fixed-price quote

    Binding, no hidden costs. You only pay once you accept it. The quote sets the schedule.

  • Binding fixed price
  • 50% deposit on order
  • Source code at project completion
See all guarantees
Personal reply from the owner

Quick request

Three fields are enough. I will get back to you in person.

By sending you agree that I use your details to handle your request. No sharing, no advertising. Privacy