Website Launch SEO Checklist for Service Businesses

A homepage that loads is evidence that one URL loaded. It is not a health certificate for the site.

A new or rebuilt website can look operational while redirects point to the wrong places, production retains staging instructions, or every service page names the wrong main URL. These failures often belong to a shared template or deployment, not one page.

The useful launch test is a representative sample: choose important page types, define what each should do, and test the same sample before launch, on launch day, and after Google recrawls.

Start with representative URLs#

Choose one URL from each type the site actually has:

Skip page types the business does not have. Add another representative when two pages use materially different templates or rules. This sample exposes shared failures; it does not replace later review of the remaining pages.

For every representative, record:

• its final URL;
• its expected status code or redirect;
• whether Google should index it;
• its expected canonical;
• whether it belongs in the sitemap; and
• which page should link to it.

That record separates a failure from a result nobody decided in advance.

Split the work correctly#

The owner decides what should happen and checks the evidence. The builder proves the implementation.

The owner should:

• choose the representative page types and expected results;
• confirm Search Console access;
• ask for a simple pass/fail launch record;
• spot-check important pages and old URLs in a normal browser; and
• route technical failures back to the builder.

The builder or technical implementer should verify:

• status codes, redirect chains, and host or protocol normalization;
• robots.txt, noindex, and HTTP-header directives;
• canonical markup and signal consistency;
• rendered HTML, important content, and internal links; and
• sitemap inclusion and exclusion rules.

The owner does not need to inspect raw HTML, headers, redirect chains, or sitemap internals personally.

Before launch, decide what production should do#

Final host#

Choose the final HTTPS hostname and whether it uses www or no www. Internal links, canonicals, redirects, and sitemap URLs should use that same form.

Old-to-new URL map#

Map old URLs before the switch. A page with a genuine replacement should receive a page-specific permanent redirect. Do not send every old page to the homepage. An intentionally removed URL should return an appropriate missing response unless a genuinely useful replacement exists.

Indexing policy#

Record which page types should appear in Google. The builder should verify that production did not inherit staging authentication, noindex, crawler restrictions, or hidden CMS settings. noindex asks search engines not to include a page in their index.

Canonical policy#

A canonical identifies the preferred main URL when similar URLs exist. The builder should verify that each primary page names its own final production URL, not staging, the old host, or another copied page.

Sitemap policy#

A sitemap lists URLs you want search engines to discover. The builder should include final, indexable, canonical production URLs and exclude redirects, missing pages, staging URLs, and deliberately non-indexable pages.

Search Console access#

Confirm access to the Google Search Console account entry for the final live site before launch.

Launch day: test production in order#

The owner reviews the pass/fail record and browser behavior. The builder produces the technical evidence.

A. Responses and redirects#

A status code is the server's numeric result, such as 200 for success or 404 for a missing page. The builder verifies that:

• intended live pages return a successful 200 response with their actual content;
• applicable http URLs make one clean permanent redirect to https;
• the alternate www or non-www hostname makes one clean permanent redirect to the chosen hostname;
• the old production hostname makes one clean permanent redirect to the new hostname when the domain changed;
• moved URLs redirect once to the correct replacement;
• redirects do not loop or travel through unnecessary chains;
• intentionally removed pages behave as planned; and
• essential images, scripts, and styles load.

The owner can spot-check final destinations in a normal browser. Raw responses and redirect-chain evidence belong with the builder. If several representatives fail alike, repair the shared launch failure before inspecting page copy.

B. Crawl and indexing permission#

The builder verifies production robots.txt, which controls where crawlers may go, and confirms it does not block intended public sections. It is not a reliable way to exclude a URL from Google's index because Google generally needs to crawl a page to process noindex.

The record should show that intended indexable pages have no noindex, while deliberately excluded pages retain it. The builder should inspect copied headers, templates, CMS settings, or plugins for a shared wrong rule.

C. Canonical URLs#

The builder verifies that each primary page declares its final production URL. Redirects, internal links, sitemap entries, and canonical markup should agree. The evidence should expose copied canonicals or production pages still naming staging.

A canonical is a signal, not a guaranteed command. Google can choose another version when signals disagree.

D. Rendered content#

Rendered content is what Google receives after scripts run. The builder should use Search Console's live URL test on the priority representatives. The owner reviews whether the evidence shows:

• the correct title and primary heading;
• substantive visible content;
• the intended primary next step; and
• no obviously missing or blank page output.

The builder confirms rendered HTML, important internal links, canonical markup, and other implementation-level output.

The live test can confirm current access and rendered output. It cannot guarantee indexing, ranking, or Google's eventual canonical choice.

E. Internal links and sitemap#

The owner can confirm that important links reach sensible final pages in a normal browser. The builder verifies that links point directly to final URLs, no important representative is orphaned, and sitemap entries return their expected result. Remove staging, redirecting, missing, and non-indexable URLs, then submit the sitemap in Search Console.

Sitemap submission helps discovery. It does not guarantee crawling or indexing.

F. Search Console sample#

The builder should inspect a restrained priority set—the homepage, primary service page, one secondary page type, and one article when applicable—run the live checks, and request indexing once for that limited set after they pass. The owner reviews the resulting pass/fail record. Do not submit every URL manually or repeat requests every day.

After launch, look for patterns#

Recheck after Google has had an opportunity to recrawl the site. Timing varies. The useful question is whether the reported condition changed, not whether a fixed number of hours passed.

Search Console's URL Inspection tool diagnoses one specific URL. The Page Indexing report exposes repeated conditions across the site or a page type. The Sitemaps report shows whether Google can process the submitted sitemap; it does not promise what Google will crawl or index.

Route the pattern before making more edits:

• If one URL fails, diagnose that URL.
• If a whole page type fails, send its shared template, directive, canonical, rendering, or linking rule back to the builder.
• If many old URLs fail, send the redirect map back to the builder.
• If Google chooses unexpected URLs, send the canonical and duplication signals back to the builder for reconciliation.
• If pages are indexed but search traffic changed, move into search-performance or migration-impact diagnosis.
• If indexing is intact but forms, calls, booking, or tracking broke, that is Website Fixes or operational QA, not an indexing diagnosis.

Record the first failed condition for each representative URL, route technical failures back to the builder, and rerun the same sample before widening the review. I would not call the launch complete until the important page types behave correctly.