Make the production site retrievable
List the pages you want found: usually the home page, core product or service pages, key categories, support pages, and original articles. Record each final HTTPS URL and whether it is intended for search. Test the public production address in a logged-out browser; staging, preview, and logged-in views can behave differently.
Check for password walls, sitewide noindex directives, robots rules, errors, redirect chains, and missing render-critical assets. Robots.txt manages crawler access; Google says it is not a way to keep a web page out of search. Use access control for private content and noindex for public pages deliberately excluded from search.
Separate indexable public pages, deliberate exclusions, and private areas before testing.
Load the preferred URL and relevant HTTP, host, slash, and legacy variants.
Choose one preferred URL per content item
A canonical URL is the representative address for duplicate or very similar content. Decide the preferred host, slash convention, and treatment of parameters, printable pages, and retired paths. Navigation, XML sitemaps, canonical links, and redirects should name that same address.
Use a permanent server-side redirect when removing or consolidating a duplicate. On indexable HTML pages, use an absolute rel=canonical link in the page head, including a self-referencing link on the preferred page. Google describes redirects and canonical annotations as strong signals, sitemap inclusion as weaker, and still makes its own canonical choice.
For each meaningful variant, record its source, destination, canonical, and reason.
Do not list one URL in the sitemap while declaring or linking to another as canonical.
Redirect HTTP variants to the working HTTPS preferred address.
Make priority pages clear and useful
Write a unique, concise page title that accurately identifies the offer or answer. Add a short, page-specific meta description as a candidate summary, not a promise of what Google will display. Google may generate a title from several signals and a snippet from page content or sometimes the description. Put the essential explanation and next step in visible copy.
Use descriptive headings and natural language that answers the visitor’s task. Avoid copied text and near-identical pages with little unique value. Provide descriptive alternative text for meaningful images. Do not spend launch effort on a keywords meta tag: web.dev says search engines no longer consider it useful.
A reader can tell pages apart from their titles without repetitive terms.
The page answers its central question before asking for a sale or sign-up.
Connect the site with useful internal links
Internal links are links between pages on the same site. They help visitors navigate and help Google find content. Link from the home page and relevant hubs to priority pages, using anchor text that identifies the destination. Add contextual links when they answer the visitor’s next question; a long footer list cannot replace an understandable structure.
Use canonical URLs in navigation, breadcrumbs, related-content modules, and calls to action. On a small site, click every primary route. On a larger site, use a crawl tool your team trusts to investigate orphaned priority pages, broken links, and unexpected response codes.
Every priority page needs a useful path from a menu, hub, or related page.
Check mobile menus, forms, accordions, and consent overlays as well as desktop links.
Publish a clean sitemap
An XML sitemap tells search engines which pages and files you consider important. It can support discovery for a new site, but it does not guarantee crawling or indexing. If a CMS generates one, inspect it. Include preferred public URLs intended for search; exclude redirects, errors, test pages, and URLs blocked from indexing.
Keep the sitemap at a stable location and submit it in Search Console if appropriate. It complements, rather than repairs, internal linking, content quality, and crawl access. Use specialized sitemap extensions only when they match the live implementation.
Match sitemap URLs against the page inventory and canonical map.
Confirm newly preferred pages appear and retired URLs disappear.
Measure discovery and diagnose targeted URLs
Verify ownership of the production property in Google Search Console. Submit the sitemap if used. Inspect a representative sample: the home page, each important template, a recently changed page, and a high-value migration URL. URL Inspection provides current index information and can test a live URL; use it to investigate a symptom, not to request every URL by habit.
Record launch date, URL conventions, sitemap address, priority pages, and exclusions. Review Search performance for impressions, clicks, queries, pages, and countries. Search Console is Google-specific and data can take time to appear, so it is diagnosis evidence, not instant proof that every search engine has processed the launch.
Save tested URLs, observed result, date, and owner for later comparison.
Check indexing exclusions, security issues, and Core Web Vitals alongside page-level tests.
Make SEO a release and remediation check
Include the page inventory, redirects, canonicals, sitemap, and representative live-URL checks in the launch record. Status Is UP treats this as proactive uptime optimization and remediation: expose delivery or configuration defects before a release and make a controlled correction when one is introduced. Availability is not a ranking guarantee.
Name the person who can approve a focused rollback if a release breaks a public route, page head, navigation, or sitemap generation. Retest the affected preferred URLs after the fix. A public-route preflight reduces avoidable delivery failures but cannot predict an engine’s crawling, indexing, or rankings.
Test representative public routes and assets after deployment, not only on staging.
Document who can reverse a harmful routing, template, robots, or sitemap change.