SEO Checklist Before Launching a New Website

A new website launch is not complete when the design looks attractive in a preview. The production server might still carry a staging noindex directive, a contact form may fail on mobile, an important service page could have an incorrect canonical, or old URLs may send customers to the wrong destination. Search engine optimisation at launch is best treated as a release-quality process: define which pages should exist, preserve relevant old routes, confirm the live output and make someone responsible for monitoring the first days after the change. This checklist explains the practical dependencies and distinguishes tests a business can complete directly from later Google indexing decisions it cannot guarantee.

Build the launch inventory before changing DNS

List every important planned public URL with its purpose, page type, canonical destination, responsible editor and intended indexing status. Include the homepage, service or product pages, contact route, policy pages and substantial guides. Where a redesign replaces an existing site, list old URLs that receive links or meaningful visitors. A spreadsheet of addresses is useful only if each row describes what the customer should find after launch. Two nearly identical articles may not need separate destinations, while two services with genuinely different eligibility rules probably do.

Decide which pages are ready for the public. Remove test text, placeholder prices, invented reviews and unsupported claims. Verify business names, location coverage, contact details and service scope with the operational owner. A beautiful page with inaccurate content is still a launch defect. If a page must remain private, set proper authentication rather than assuming a search directive protects it.

Use the inventory as a release gate, not as another document nobody maintains. Record an owner and an acceptance test for each important group. A live service URL should answer the promised subject and offer a usable next step. An educational guide should have a complete explanation and sources relevant to its claims.

Preserve valuable URLs and prepare redirect mappings

If replacing an older site, map each existing important address to the most relevant successor. Do not redirect every old article to the homepage merely because the new design has fewer pages. A visitor opening a legacy guide expects related information; an unrelated landing page can interrupt the task. Use suitable permanent redirects for genuine lasting moves, minimise chains and test both old and new addresses. Update important internal links to their final destinations rather than depending entirely on redirects.

Google's site move with URL changes guidance describes mapping, redirects and post-migration monitoring. It does not promise unchanged positions or an exact processing date. Review sitemaps and canonical references along with redirects. A technically successful HTTP response is not enough if the final article addresses a different topic.

For discontinued products or withdrawn content, decide whether there is a genuinely equivalent resource. An appropriate not-found or gone response may be more honest than a misleading redirect when no replacement exists. Keep the reason documented so future audits distinguish deliberate removal from an accidental 404.

Verify HTTPS, hostnames and server responses

Choose the preferred hostname and ensure the site serves a valid HTTPS certificate. Test representative deep URLs as well as the homepage. HTTP or alternate hostnames should lead to the correct equivalent destination where intended, not discard the path. Check for redirect loops, mixed-content resources and failures when navigating from another device. Ensure the domain and certificate have a clear owner responsible for renewal.

Inspect actual HTTP statuses on public pages. An error page styled to resemble successful content can still return the wrong response. Conversely, an apparently blank page may have a successful response but fail to render essential content. Test the delivered HTML and browser experience together. For applications using multiple backends or content delivery networks, confirm that the public route reaches the correct production environment.

Do not optimise a server response by caching customer-private content publicly. Public editorial pages and authenticated account pages need different cache policies. A launch can fail even with fast pages if confidential data is accessible to unauthorised visitors.

Remove staging indexing restrictions carefully

Staging sites are often intentionally excluded from search. When a production release occurs, those exclusions can be carried over accidentally. Inspect public robots directives and appropriate response headers on representative intended pages. A noindex instruction may prevent indexing even when customers can load the URL. Conversely, robots.txt blocking can prevent a crawler from seeing a noindex directive placed on the page. These mechanisms are not interchangeable.

Use Google's noindex guidance to understand how indexing controls work. Decide which pages genuinely need to be eligible for search and which should remain excluded. A thank-you page may have a legitimate exclusion, while a core service page accidentally blocked is a serious defect. Do not remove every restriction across the entire site without checking access and privacy requirements.

For a verified property, Search Console URL Inspection can help investigate a particular address. A page being eligible for indexing or appearing in a sitemap does not guarantee Google will index it. Report eligibility and later indexing observations separately.

Check canonical destinations and duplicate variants

Canonical signals help identify preferred representatives among duplicate or very similar URLs. A shared template pointing every service page to the homepage can conflict with the desired architecture. Inspect actual canonical elements and their targets on representative public URLs, including products with variants and pages reached through tracking parameters. Ensure internal navigation and sitemaps agree with the preferred addresses where appropriate.

Google uses multiple signals when selecting canonical URLs, so a tag is not an unconditional command. If two pages serve distinct questions, avoid collapsing them merely to reduce a duplicate-content warning. If two URLs truly repeat the same resource, choose a maintainable preferred destination. Google's canonical guidance explains the technical distinction.

Do not change every URL solely to insert a shorter keyword phrase just before launch. Unnecessary migration increases redirect, analytics and link-maintenance work without guaranteeing any ranking advantage.

Inspect titles, headings and the full public answer

Every important page should have an accurate title and a visible heading that describe the same subject. They may differ naturally in wording, but a title promising a specialist guide should not lead to generic sales content. Review the opening paragraph, supporting sections and important claims. Generic default titles across several URLs may reveal a shared template issue. Fix the actual source rather than manually editing dozens of fields if the renderer continues generating the wrong value.

Meta descriptions can offer a candidate summary, but Google may show a different excerpt. Write truthful page-specific summaries without claiming an exact snippet. Check public HTML rather than relying on the editor preview. An image caption should identify a historical screenshot as historical, not evidence of a current product or measurement. If internal editorial notes appear in the published article, treat that as a confidentiality defect in the renderer.

Keep source references working and relevant. An external link must support the claim it accompanies. Check that a licensed image has the correct creator, source and applicable conditions, not simply that its URL responds.

Make navigation and mobile reading work

Test whether important pages can be reached from meaningful menus, category pages and contextual links. A sitemap assists discovery but cannot replace useful navigation. Check ordinary crawlable anchor elements, link labels and final destinations. A menu requiring hover may be hard to operate on a phone, while a scripted control may not behave like a normal anchor. Google's link best practices provide a technical reference.

Test widths around 320, 375 and 768 pixels, plus representative devices where available. Long titles should wrap, images should scale without hiding essential details and comparison tables should scroll within a labelled region rather than force the entire page sideways. Check keyboard navigation and visible focus states. Forms need accessible labels and clear errors. A responsive stylesheet alone does not prove that every person can use the resulting interface.

Perform an end-to-end contact or purchase test using approved test data. Confirm the backend receives the request, not merely that an analytics click event fired. Test unsuccessful submissions as well to make sure recovery works.

Check performance without sacrificing functionality

Large images, blocking resources and heavy widgets can delay the main content. Use suitable diagnostics to understand Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Those metrics describe different aspects of performance. A low synthetic score can indicate a problem worth investigating, but a perfect result does not prove accurate content or working business actions.

Reserve dimensions for media to avoid unexpected movement, serve suitable image sizes and consider whether below-the-fold assets can load later. Do not lazy-load a critical above-the-fold image indiscriminately. Defer nonessential scripts only after confirming that menus, forms, consent interfaces and other essential components continue to work. Compare representative templates rather than assuming the homepage reflects the entire site.

Document the tool, date, device and conditions of performance tests. A single laboratory run cannot represent every visitor. Do not invent measured improvements or attribute a future ranking change solely to a page-speed modification.

Set up measurement with verified definitions

Authorised Search Console access can show search-side impressions and clicks, while website analytics may show sessions and events. These measurements are not identical. Define what a successful enquiry, cart action or completed purchase means and test the event collection. A form click cannot prove a qualified customer lead. Ensure privacy and consent requirements are addressed before deploying tracking.

Record a baseline where reliable data exists. A newly launched site may not have enough observations for meaningful trends, and percentages computed from tiny counts can be misleading. Keep a dated register of releases and incidents so later changes can be investigated. Someone should own Search Console access, analytics configuration and the response to unexpected technical errors.

Use an XML sitemap reflecting intended canonical pages and submit it through appropriate channels if authorised. Submission may support discovery, but does not make every URL indexable or guarantee search positions.

Perform a public release check and monitor afterwards

After the deployment, request the real canonical URLs and inspect the rendered output. Verify titles, content, links, images and comparison tables. Test forms, mobile navigation and privacy-sensitive paths. A saved database record is a useful confirmation of persistence but is not evidence that the public website displays the new version. If caching or rendering serves stale content, investigate the delivery layer rather than repeatedly rewriting the same article.

Maintain a launch-day defect register with severity, owner and acceptance evidence. Check important pages again after caches settle, DNS changes propagate or content imports complete. Record whether a failure was repaired and publicly verified, not just assigned to someone. A site launch is an operational handover: ongoing content ownership matters after the original designers depart.

The most useful launch checklist is short enough to follow and detailed enough to expose serious defects. Prioritise the pages and journeys that matter most to customers; preserve truthful content, important routes and secure access; then monitor real evidence. Google's SEO Starter Guide and site-move guidance support the approach, but neither can certify an individual launch without public tests.