A small business website can look finished while its important pages still carry a staging noindex rule, point to the wrong canonical URL, or disappear from the mobile navigation.

This checklist covers a practical release review for a service business website. Run it against the production domain before announcing the launch, then repeat the public checks after deployment. For an online store, include a category and product page in the sample.

1. Decide which pages should appear in search

Start with a short URL inventory: the homepage, service overview, one service detail page, an article, and the contact page.

For each public page intended for search, check:

  • The final response is 200 OK and contains the expected content.
  • Neither the HTML nor the X-Robots-Tag response header contains an unintended noindex.
  • robots.txt allows the crawling needed to inspect that page.

Keep deliberate exclusions where they belong. Private staging environments should have access controls. Also, blocking crawling does not reliably remove an already known URL from search: Google must be able to fetch a page to process its noindex rule.

Reference: Google's noindex documentation.

2. Inspect redirects on real page paths

Test HTTP and HTTPS, plus www and non-www versions, using a service page as well as the homepage. A redirect should preserve the intended destination.

Replace this example URL with your own:

curl -sS -L -D - -o /dev/null 'http://example.com/services/' 

This prints the response headers along the redirect chain while discarding the body. Check each status and Location header, then the final response.

Use 301 or 308 for permanent moves. Use temporary redirects for genuinely temporary changes. Avoid loops, unnecessary hops, and a rule that sends every old page to the homepage.

Reference: Google's redirect guidance.

3. Check the canonical on each page type

A unique page can declare its own preferred URL:

<link rel="canonical" href="https://example.com/services/" /> 

Look for staging domains, incorrect hosts, or templates that give every service page the same canonical.

Canonical signals are intended for duplicate or very similar pages. A separate service page with distinct content should not automatically point to the homepage. Google can select a different canonical, so also check its indexed decision later.

Reference: Canonical URL guidance.

4. Connect navigation and sitemap entries

Reach each important page through ordinary navigation or a relevant contextual link. Use crawlable HTML links with real destinations:

<a href="/services/">Explore our services</a> 

In the XML sitemap, list the preferred public URLs you want indexed. Remove staging addresses, redirects and intentionally excluded pages. Check that listed URLs work.

A sitemap helps discovery; it does not guarantee indexing or replace useful navigation.

References: Crawlable links and building a sitemap.

5. Review titles and descriptions in context

Give important pages distinct, descriptive titles and clear visible headings. Write descriptions that accurately summarise their contents.

Avoid repeating the same generic title across every service page. Google can generate different title links and snippets, so these fields are inputs rather than a guaranteed search-result preview.

References: Title links and search snippets.

6. Test the mobile experience and performance

On a phone, open the menu, follow a service link, read the main content, and complete a test enquiry. Check whether banners obscure controls or elements shift while loading.

Use PageSpeed Insights to investigate performance. Current good Core Web Vitals thresholds are:

Metric Good threshold
Largest Contentful Paint (LCP) 2.5 seconds or less
Interaction to Next Paint (INP) 200 milliseconds or less
Cumulative Layout Shift (CLS) 0.1 or less

These thresholds apply at the 75th percentile of real visits, with mobile and desktop considered separately. A new site may lack sufficient field data. Lab testing helps find issues; a Lighthouse score alone does not establish real-world performance.

References: Core Web Vitals and Google Search guidance.

7. Verify the public deployment in Search Console

After launch, inspect representative URLs using Search Console's live test. Review what Google can fetch and render.

Then distinguish the live test from the indexed report: the former checks the current page, while the latter reflects Google's indexed information. The live test does not predict Google's canonical selection. Requesting indexing also does not guarantee inclusion.

Reference: URL Inspection documentation.

Record a clear result for each check

A small release log makes fixes easier to verify:

Check Evidence to record
Public access Final status, visible content and robots directives
Redirects Tested starting URL, each hop and final destination
Canonical Declared URL and whether it matches the page
Discovery Internal link and sitemap entry
Mobile usability Device, task tested and any obstruction
Search Console Test date and live versus indexed result

Fix launch blockers first: accidental exclusions, broken destinations, incorrect canonical templates and unusable mobile navigation. Keep remaining improvements in a dated follow-up list.

About the author: Vladyslav Yanchenko works on SEO and website structure at Salestudia in Germany. The agency's SEO audit and optimisation overview explains the broader scope of that work.