The website relaunch runbook: 30 days before and 30 days after

A relaunch is decided in the month before switchover and judged in the month after. This runbook covers both, in six phases, each ending in a gate: a short list of conditions that must pass before the next phase starts. It follows Google's documentation on site moves with URL changes, which is the closest thing to an official procedure, and adapts it for an industrial company whose site earns enquiries through specific product and capability pages.

The runbook partners the 90 day pre-launch runbook, which sequences a product launch. The logic is the same: each phase depends on the output of the one before it, so the order matters. Name one owner on the business side to sign each gate, as described in a website relaunch is a launch.

Days 30 to 22 before: crawl and inventory the old site

The first phase produces a complete list of the old site's URLs and a baseline of what they earn. Nothing else in the runbook works without it, because a URL missing from the inventory is a URL with no redirect.

Google suggests building the list from several sources: the current sitemaps, server logs or analytics, the Links report in Search Console, and the CMS. Include PDFs, images and downloads, which industrial sites often have in large numbers and which carry links from distributors and tender documents. Run a crawler over the old site as well, to catch pages that exist but appear nowhere else.

Against each URL record organic visits over the last twelve months, enquiries attributed to it where analytics allows, and whether external sites link to it. Then mark each one: keep (same content at a new URL or the same URL), merge (content combined into another page), or remove.

Gate: every URL in the inventory carries a keep, merge or remove decision, and the baseline of organic visits, enquiries and indexed pages is saved where the owner can find it after switchover.

Days 21 to 15 before: build and test the redirect map

The redirect map is a table with one row per old URL and the new URL it should reach. Build it from the inventory, then test it on staging before anyone trusts it.

Google's redirects documentation recommends server-side permanent redirects wherever possible and treats JavaScript redirects as a last resort, because rendering can fail. The site move guide adds two rules: redirect straight to the final destination rather than through a chain, and do not send many old URLs to an irrelevant page such as the new homepage.

Test by script rather than by clicking. Feed the list of old URLs to a tool that requests each one against the staging host and records the status code, the number of hops and the final status. Any row that ends anywhere other than a single redirect to a live page, or a deliberate 404 or 410, is a fault.

Gate: every old URL with traffic, enquiries or external links reaches a live page in one hop, and the removals are a deliberate list rather than an accident.

Days 14 to 8 before: run the staging checks

This phase prepares the settings that change at switchover, so that the day itself is a sequence of known steps rather than a set of decisions. Staging must stay out of the index until launch, and the launch configuration must be written down before it is needed.

• Keep staging out of the index. Password protection is the safest method. If staging uses noindex instead, remember that Google's noindex documentation says the page must not also be blocked in robots.txt, or the crawler never sees the noindex.
• Prepare the launch robots.txt. Google says to make sure the new site's robots.txt blocks only the parts you intend. Write the production version now and keep it separate from the staging one.
• List the pages where noindex will be removed. The site move guide recommends preparing this list in advance. On launch day it becomes a checklist.
• Check canonicals and internal links. Each new URL should carry a self-referencing canonical on the production host, and internal links should point at new URLs rather than relying on redirects.
• Carry over verification. Keep the Search Console verification file or tag working on the new site.
• Check capacity and hosting. Google notes that it crawls more heavily after a move. If the host changes, Google's guide to moving hosting without URL changes suggests lowering the DNS TTL in advance, to a few hours.

Gate: the production robots.txt, the noindex removal list, the canonical rules and the redirect configuration are written, reviewed and ready to deploy.

Days 7 to 1 before: confirm content parity and freeze

Content parity means the new page for each kept URL says at least what the old page said that earned it traffic or enquiries. Check it page by page for the top fifty landing pages from the inventory, and by sample for the rest.

For each pair compare the title, the main heading, the specification tables, the body text, image alt text and structured data. The commonest losses on industrial sites are specification tables shortened for design reasons, grades or standards dropped from a product page because they looked cluttered, and text moved into tabs or sliders that load only after a click. A gain is fine. A loss on a page that brought enquiries needs a reason written next to it.

Freeze content three days before switchover. Late edits are where parity breaks without anyone noticing. SEOtop10 sets out what a rebuild can cost a company when this phase is skipped.

Gate: the owner signs off parity for the top pages, the rollback plan is written, and a go or no-go decision is recorded.

Day 0: switch over

Switchover is the execution of decisions already made. Google recommends a period of low traffic and changing one thing at a time where possible, so avoid combining the redesign with a domain change and a host change on the same day if the schedule allows.

1. Deploy the new site and put the redirect map live.
2. Remove temporary noindex rules and deploy the production robots.txt.
3. Run the redirect test script against the live host.
4. Submit the new sitemap in Search Console. Keep the old sitemap available for monitoring.
5. If the domain changed, use the Change of Address tool, which Google says is only for domain or subdomain moves.
6. Test every enquiry form end to end until messages land in the sales inbox.
7. Update the Business Profile, LinkedIn page and directory listings to the new URLs where they changed.

Gate: redirects, indexability, sitemap, forms and analytics all pass on the live site within the first hour, or the rollback plan is used.

Days 1 to 30 after: watch, then review

The month after switchover is for watching closely and fixing quickly. Read the signals daily for the first week, then weekly until day thirty.

Daily in week one: server logs for 404s and 5xx errors, the page indexing report in Search Console, enquiries received against the same week last year, and any old URL reported as broken by sales or distributors. Google's hosting move guide says a temporary drop in crawl rate immediately after launch is normal, followed by a steady increase over the next few days.

Weekly after that: the Sitemaps report, where Google says the number of pages indexed from the old sitemap should drop to zero over time; organic visits and enquiries against the baseline; and the top landing pages from the inventory, checked one by one. Google says small and medium sites can take a few weeks for most pages to move and that rankings may fluctuate in that time. Keep the old hosting until traffic to it reaches zero, and keep the redirects for at least a year.

For a structured self-assessment of the new site once it settles, EbizIndia publishes a website self-check for manufacturers. For reading a month of data without reacting to noise, use the post-launch 30 day measurement plan.

Gate: at day thirty, the owner records organic visits, enquiries and indexed pages against the baseline, lists the faults found and fixed, and writes down the one thing to fix next.