Technical SEO for Developers: A Pre-Launch Website Audit Checklist

Overview

Technical SEO is the part of website quality that determines whether search engines can access, understand, and reliably reach your pages. It does not replace useful content or clear information architecture, but it provides the foundation those elements need.

A practical website SEO audit should test the site as both a user and a crawler would experience it. That means checking the rendered page, the raw HTML, HTTP responses, internal links, metadata, structured data, and deployment configuration. Automated tools can identify clues, but developers still need to confirm whether each result is intentional.

Run this checklist in a production-like environment before launch, then repeat the most important checks after the domain goes live. Keep a record of the expected canonical domain, public URL patterns, redirect rules, sitemap location, and any pages that should remain private. These decisions make it easier to distinguish a real defect from an intentional configuration.

For a broader launch workflow, compare this guide with the pre-launch website checklist for developers. If the project uses separate environments, the staging vs production workflow guide can help clarify which checks belong in each environment.

Checklist by scenario

1. A new website or domain

• Confirm the public hostname. Choose the canonical version of the domain and decide whether alternate hostnames should redirect to it. Test HTTP and HTTPS, the www and non-www variants, and any temporary deployment URL.
• Check HTTPS. Load important URLs over HTTPS and inspect the browser address bar for certificate or mixed-content warnings. Use the browser’s developer tools to identify insecure images, scripts, stylesheets, fonts, or API requests.
• Inspect the homepage response. Run curl -I https://example.com/ and confirm that the response is successful and comes from the intended host. Follow redirects with curl -IL https://example.com/ when validating the final destination.
• Review the robots.txt file. Visit /robots.txt directly. Confirm that it is a plain text response, does not accidentally block the whole site, and identifies the sitemap location when appropriate. A robots.txt file controls crawling instructions; it should not be treated as a replacement for access control.
• Validate the XML sitemap. Open the sitemap URL, check that it returns successfully, and confirm that listed URLs are canonical, publicly accessible, and intended for indexing. Remove redirects, error pages, duplicate variants, and private URLs. For more detail, use the XML sitemap validator checklist.
• Test indexability signals. Inspect the HTML for a robots meta tag and, where relevant, an X-Robots-Tag HTTP header. Make sure an accidental noindex directive is not inherited from staging or a framework default.

2. A redesign or migration

• Build a redirect map. Match each important old URL to its most relevant new destination. Test representative pages, including deep links, trailing-slash variants, changed file extensions, and URLs with common query parameters.
• Avoid redirect chains. A retired URL should normally resolve through the shortest intentional path to the final canonical URL. Use curl -IL or the Network panel to inspect every hop.
• Compare old and new templates. Check titles, meta descriptions, headings, canonical URLs, internal links, structured data, language attributes, and important body content. A visual match does not guarantee that the HTML and metadata remain equivalent.
• Update internal links. Links should point directly to the new URL rather than relying on redirects. Search the codebase and generated output for old paths, staging hostnames, and hard-coded development URLs.
• Recheck the sitemap and canonical tags. Both should use the new URL structure and the same preferred hostname and protocol.

For a fuller migration-oriented reference, see the technical SEO checklist for new websites and redesigns.

3. A JavaScript application or dynamic site

• Compare source and rendered HTML. View the page source, then inspect the rendered DOM in browser developer tools. Confirm that important text, links, titles, canonical tags, and structured data are available in the intended rendering path.
• Test direct navigation. Open a deep URL in a new browser tab, refresh it, and load it without first visiting the homepage. Server or hosting rules must return the correct application shell or page rather than a 404.
• Check client-side routing. Verify that route changes update the URL and document title correctly. Test back, forward, refresh, and shared links.
• Watch for blocked resources and failures. Use the Console and Network panels to identify failed JavaScript bundles, API calls, fonts, or assets that affect page content or layout.
• Review loading behavior. A page that initially displays an empty shell may be difficult to use and may complicate automated inspection. Ensure core content and navigation become available reliably.

4. A performance-sensitive launch

• Measure representative pages. Test the homepage, a content page, a listing page, and a conversion or application page. Do not judge the entire site from one template.
• Use browser performance tools. Run Lighthouse or an equivalent audit in a consistent environment, then inspect the underlying opportunities rather than focusing only on a single score. The Lighthouse score improvement guide covers practical fixes and prioritization.
• Check layout stability. Reserve space for images, advertisements, embeds, and dynamically inserted components. Unexpected movement can make forms and navigation difficult to use.
• Inspect asset delivery. Confirm that images have appropriate dimensions and formats, unused scripts are limited, and cache or compression settings match the deployment architecture.
• Test on a constrained connection. A page that works on a fast development connection may expose slow third-party requests, oversized assets, or long main-thread tasks under less favorable conditions.

What to double-check

Canonical URLs and page identity

Every indexable page should communicate its preferred URL consistently. Inspect the canonical link element in the final HTML and compare it with the address in the browser, the sitemap entry, internal links, and redirect destination. Watch for absolute URLs pointing to staging, the wrong protocol, the wrong hostname, or a different URL variant.

Canonical tags are signals, not permission to publish contradictory URL versions. If several URLs display the same content, decide whether they should redirect, use a canonical reference, or remain independently useful. Test pagination, filtered listings, print views, and query-string variations deliberately.

Structured data and metadata

Check that each important template has a meaningful title, an appropriate meta description where used, one clear primary heading, and usable social sharing metadata. Confirm that values are generated from the correct record rather than copied from a default template.

Validate structured data syntax and review the actual values exposed in the markup. Remove empty properties, placeholder text, invalid dates, and markup describing content that is not visible or relevant on the page. Treat structured data as a description of the page, not a way to add claims that the page does not support.

Security, status codes, and access

Check that public pages return the status you expect, missing pages return an appropriate not-found response, and restricted areas are not exposed through navigation, sitemaps, or client-side bundles. Use the Network panel and command-line requests to test authenticated and unauthenticated behavior separately.

Review deployment headers and caching rules carefully. A cache configuration that serves one user’s personalized response to another user is a serious application defect, while a header that blocks needed assets can create an incomplete page. Keep SEO validation connected to the wider security and release review.

Accessibility and discoverability together

Ensure navigation uses real links where navigation is intended, images have useful alternative text when needed, form controls have labels, and interactive elements can be reached without a mouse. These checks improve usability and also make the site structure easier to interpret. Use browser inspection tools and keyboard testing alongside automated audits rather than relying on either alone.

Common mistakes

• Leaving staging directives in production. A site-wide noindex rule, password gate, disallow rule, or temporary hostname can survive a rushed deployment.
• Submitting every discovered URL. A sitemap should represent the clean, intentional set of indexable URLs, not every route generated by a database or application.
• Using robots.txt to hide sensitive content. Crawling instructions do not provide authentication. Protect private resources at the application or server layer.
• Testing only the homepage. Template errors often affect deep pages, pagination, product or article records, and dynamic routes differently.
• Fixating on one audit score. A score can identify opportunities, but it does not replace checking redirects, page content, indexing directives, or real user flows.
• Ignoring the final deployment. Build pipelines can rewrite URLs, omit files, change headers, or inject environment variables. Re-run critical checks against the actual public deployment.
• Forgetting observability. Record the release time, expected URL behavior, and important checks so that a later error can be traced to a specific change.

When to revisit

Use the full checklist before a new site launch, domain change, redesign, framework migration, major navigation change, or hosting move. Repeat a focused version after each production deployment that changes routing, rendering, metadata, caching, or asset delivery.

Schedule another review before seasonal planning cycles or major promotional periods, especially when landing pages, redirects, tracking scripts, or content templates are added. Revisit the checklist whenever your build pipeline, hosting provider, CMS, JavaScript framework, or deployment workflow changes.

For the final pass, assign an owner to each item and save evidence: response headers, sitemap output, redirect results, screenshots, audit reports, and links to tested pages. Start with the highest-risk checks: accidental blocking, incorrect canonical domains, broken redirects, unavailable deep links, insecure resources, and failed page loads. Then run a small post-launch audit against the live domain. This turns a one-time technical SEO checklist into a repeatable developer workflow rather than a last-minute inspection.