Approve launch when important public pages are accessible, production URLs agree, mobile content is available, and redirects and sitemaps pass documented tests. Ask your delivery team for evidence against each check, not simply confirmation that SEO is done. This technical SEO checklist identifies proposed launch blockers, follow-up tasks and checks to repeat once the website is public.
Define which pages should appear in search
Start with an approved page inventory: homepage, services, products, useful articles and other public business information. Separately mark private areas, staging pages and utility URLs that should not appear in search. The marketing lead owns these decisions; the developer implements them. Without this inventory, a technically valid sitemap can still omit your most important service.
| Field | Record for each intended search page |
|---|---|
| URL and purpose | Full production URL; what the page helps visitors do |
| Status and indexing intent | HTTP response; intended for search or deliberately excluded |
| Canonical | Declared preferred URL; matches the approved destination |
| Title | Actual title text; accurate and distinct |
| Mobile check | Primary content present without interaction; test evidence |
| Sitemap inclusion | Included or excluded, with a reason |
| Issue owner | Named person responsible for any correction |
| Retest result | Pass or fail, date, environment and evidence link |
Request a full URL check for a small website. For larger sites, check every important page and sample each template, including unusual pages. Keep response headers, crawl exports and rendered-content evidence where relevant. Screenshots alone cannot prove HTTP status or indexing instructions. Record the tested environment because staging evidence does not establish that production settings are correct.
Check crawl access and accidental indexing blocks
Google’s minimum technical requirements include accessible pages, a successful HTTP 200 response and indexable content. A page that displays an error message while returning 200 is not a useful pass. Ask the developer to inspect the response and content without signing in, then check production crawl controls and indexing instructions. [1]
- Public access: intended pages load without passwords and return HTTP 200 with useful content.
- Crawl controls: production robots.txt does not accidentally block important pages or necessary resources.
- Indexing instructions: robots meta tags and X-Robots-Tag response headers contain no unintended noindex instruction.
- Discovery links: important pages have ordinary internal links using an anchor element with an href destination.
- Staging protection: the test website remains behind authentication; production restrictions are changed deliberately.
Robots.txt controls crawling; it does not reliably prevent a URL appearing in search. A noindex instruction asks for exclusion, but Google must crawl the page to read it. Do not combine a crawl block with noindex and assume both work together. Accidental blocks on key pages are proposed launch blockers, owned by the developer or hosting administrator. [1]
Align canonical URLs across the production website
A canonical declaration identifies the preferred URL for duplicate or very similar content. Choose HTTPS, one hostname and a consistent trailing-slash policy. Inspect actual canonical output rather than relying on a settings screen. Internal links, canonical declarations and sitemap entries should agree. Google treats canonical declarations as signals, not commands, and may select a different URL. [2]
For an ordinary unique service page, a practical pass is a self-referencing production canonical, direct internal links and the same sitemap URL. No declaration should point to staging. Do not send genuinely different service pages to the homepage through canonical tags. The developer should correct template-wide errors before launch; isolated harmless link inconsistencies can receive an agreed follow-up date.
Give important pages clear, distinct titles
Check the title element for missing text, duplicates and placeholders. A useful title describes the page, with restrained branding where helpful. The visible main heading should support the same subject. Google recommends descriptive, concise titles, but sets no fixed title-length limit. Search title links can be shortened or generated from other page signals. [3]
Test mobile content, not just mobile appearance
Google uses mobile content for indexing, so an attractive phone layout is not enough. Compare primary text, headings and links across desktop and mobile. Test each template and important exception. Essential descriptions should be available without clicking, swiping or typing to load them. Content already loaded inside an expandable section differs from content fetched only after interaction. [4]
Ask the developer to verify access to necessary JavaScript, CSS and images, then inspect rendered text as well as screenshots. For brochure sites, Softglimmer recommends essential business content in the initial HTML where practical. This reduces rendering dependency but is not a universal Google requirement; Google can render JavaScript. Missing primary mobile content is a proposed blocker. [5]
Once production is public, use Search Console’s URL Inspection to examine what Google can access and render. Distinguish a live test from an indexed-page report: a successful live test does not prove indexing. Record the inspected URL and test date, and ask the developer to investigate missing content or inaccessible resources. [1][5]
Verify redirects and their final destinations
A completely new website may have no historical URLs to map, but still needs protocol and hostname tests. Check HTTP and alternate-host versions of the homepage and important paths. Permanent 301 or 308 redirects suit permanent URL consolidation; 302 or 307 indicate temporary moves. Prefer server-side redirects when available. [6]
A pass means the expected redirect reaches the intended HTTPS page, preserves the relevant path and ends at a useful 200 response. Check status codes, loops and unnecessary chains, not just whether a browser eventually opens something. Internal links should point directly to final URLs. The developer owns corrections; broken key-page destinations should block approval.
If this website replaces an existing one
Request relevant old-to-new mappings for changed URLs. Do not redirect unrelated retired pages to the homepage simply to hide their removal. The content owner approves destination relevance; the developer tests implementation. For the wider transition, use Redesign the website. Plan the search transition. (/insights/website-redesign-seo-checklist), rather than expanding this acceptance checklist into a migration plan.
Validate the sitemap against your inventory
An XML sitemap lists URLs to help search engines discover pages. Open it without authentication and check valid output, fully qualified production URLs and any child sitemaps. Compare entries with the approved inventory. Include intended canonical pages; exclude staging URLs, redirects, errors and noindex pages. Google recommends listing canonical URLs you want in search. [7]
The developer owns sitemap generation. Staging URLs or widespread omissions need correction before sign-off; one missing article can be a scheduled follow-up if other discovery links work. Submit the production sitemap through Search Console after launch and review processing feedback. Submission helps discovery but does not guarantee crawling or indexing. [7]
Make the decision and retest production
Hypothetical worked example — not a client result: a small maintenance business is launching its first brochure website. Its homepage, three service pages and contact page are intended for search. The following findings show how to turn developer fixes into acceptance tests rather than relying on reassurance.
| Finding | Fix and owner | Acceptance test | Proposed decision |
|---|---|---|---|
| Service pages inherit staging noindex | Developer removes unintended production instruction | Headers and page output show no accidental noindex | Block launch |
| Canonicals point to staging | Developer corrects URL generation | Declared URLs match approved production pages | Block launch |
| Mobile descriptions load only after a click | Developer makes primary content available on load | Rendered text contains descriptions without interaction | Block launch |
| Alternate hostname loses service paths | Developer corrects redirect rules | Each tested variant reaches its relevant 200 destination | Block launch |
| Accurate title has slightly long branding | Content owner shortens branding if useful | Title remains clear and distinct | Follow up |
- Agree the inventory and intended indexing status with the marketing lead.
- Collect evidence, name issue owners and separate blockers from dated follow-up tasks.
- Retest corrected failures rather than closing them on a promise.
- Approve deployment subject to immediate production verification.
- Repeat access, indexing-instruction, canonical, mobile, redirect and sitemap checks on production.
- Submit the sitemap and retain the evidence sheet for ongoing ownership.
Can we require Google indexing before launch approval?
No. Pre-launch approval should concern controllable technical conditions. Google cannot inspect a protected staging site, and passing production tests still does not guarantee indexing. Review indexing after launch separately from the delivery team’s acceptance results. [1]
Must every finding delay launch?
No. Prioritise defects that prevent access, hide primary content or send important URLs to incorrect destinations. Minor title polish or an isolated sitemap omission may be a follow-up. Record the reason, owner and deadline instead of silently accepting the defect.
What should the developer hand over?
Ask for the completed evidence sheet, supporting test output, redirect rules or mappings, unresolved issues and production retest results. Agree who owns Search Console access and follow-up monitoring. Keep control of the website after launch (/insights/website-support-handover) covers the broader ownership handover.
Next step: send the evidence sheet to your delivery team and book a sign-off review before deployment. Ask them to demonstrate the passes and agree when production retesting will happen. Use A website launch checklist built around what must work (/insights/website-launch-checklist) for wider readiness checks; keep this review focused on search access and URL integrity.
Sources & further reading
Use the original guidance when checking details or planning implementation.
This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.
