Technical SEO Audit Guide

A technical SEO audit checks whether the pages that matter to your audience can be discovered, crawled, indexed, and used. Begin with a sample of important pages, compare the intended behavior with what a visitor and Google actually receive, then investigate patterns across the site. Fixing a technical issue removes a potential obstacle; it does not guarantee indexing or rankings.

1. Define the scope and baseline#

List the canonical host, important templates, recent releases, and the pages that support your main customer tasks. Include the homepage, a category page, several articles or products, and any pages affected by a migration. Record the expected status, canonical URL, and indexing policy for each.

Use Google Search Console to review page indexing and search performance, and PageSpeed Insights to investigate performance. A site crawler can help find patterns in a large URL inventory; check its configuration and independently verify important findings against the public site. A crawler's issue count is a starting point, not a list of confirmed Google indexing problems.

2. Check HTTP responses and redirects#

Request representative URLs directly, including the non-canonical host, old URLs, and a deliberately nonexistent page. A browser's network panel or a command such as the following can expose the response and redirect chain:

curl -I https://www.example.com/important-page/
curl -IL https://example.com/old-page/

Check that important pages return successful responses, intentional permanent moves lead to the right final destination, and missing pages return an appropriate error status rather than a successful page with an error message. Avoid redirect chains when they add unnecessary requests or send users to the wrong page. A 200 response alone does not prove that a page is indexed or that its content is useful. See Google's guidance on HTTP status codes and Search.

3. Review robots.txt and indexing controls#

Fetch /robots.txt on the exact host you are auditing. Check whether its rules permit the crawlers that need to access the site's public pages, and whether sensitive or private content is protected by authentication rather than just a crawl rule. For example:

User-agent: *
Disallow: /account/
Sitemap: https://www.example.com/sitemap.xml

This illustrative rule asks compliant crawlers not to crawl /account/; it does not make that path private or guarantee that its URLs stay out of an index. A blocked URL can still appear without a snippet if discovered elsewhere. Likewise, a crawler blocked by robots.txt cannot read a noindex directive on the blocked page. Use the appropriate access and indexing controls for the intended outcome (S1, S2).

The robots.txt generator can prepare draft directives. Review user-agent groups and publish the file at the correct origin, then verify the actual response. It does not change your server configuration for you.

4. Compare sitemaps with live pages#

A sitemap is a list of URLs you want search engines to consider, not a guarantee of crawling or indexing. Fetch the sitemap declared in robots.txt or submitted in Search Console. If it is an index, inspect the child sitemaps too. Sample URLs from each template and confirm that they return the expected page, are intended to be indexed, and use the canonical form.

For example, if https://www.example.com/sitemap.xml lists a guide that returns 404, restore the intended page or remove the stale entry according to the content decision. Also investigate whether the sitemap and page responses came from different deployments or caches. Submit a corrected sitemap through Search Console and monitor its processing rather than assuming submission ensures indexing (S3).

The sitemap index generator builds an index from existing child sitemap URLs. It does not crawl your site or generate the child sitemaps; create and verify those separately.

5. Inspect canonical URLs and duplicates#

For each sample page, inspect the rendered HTML for a canonical link, and check whether any HTTP Link header, redirect, sitemap entry, and internal link agrees with the intended URL. A typical self-referencing canonical is:

<link rel="canonical" href="https://www.example.com/guides/site-audit/">

A canonical declaration is a signal, not an instruction Google must follow. Use consistent signals when consolidating duplicate URLs and avoid pointing a canonical at an unrelated page, error, or redirect. URL Inspection can show Google's selected canonical for an indexed URL (S4).

Use the canonical tag manager to draft tags; test the published HTML and any reciprocal hreflang annotations separately.

6. Inspect indexability and rendered content#

Use URL Inspection on a sample of high-value URLs. The indexed report describes the version Google has processed; the live test requests the current page and does not predict whether or when it will be indexed. Compare their status, canonical selection, crawl access, and rendered HTML.

Check for accidental noindex directives, authentication walls, missing page text, and conflicting canonical tags. When an issue appears on many URLs, trace it back to the shared template or deployment rather than treating each URL as a separate defect. Request recrawling after fixing important pages where suitable, but do not treat a request as a guarantee of inclusion.

7. Follow internal links as a visitor#

Starting from navigation and relevant articles, follow actual HTML links to important pages. Confirm the destination exists and the anchor text describes where it leads. Look for links to retired URLs, unnecessary redirects, pages reachable only through client interactions, and valuable pages with no relevant inbound links. Links should help readers continue a task; add them where they make sense rather than repeating the same anchors everywhere.

Our SEO and meta tags analyzer reviews metadata that you enter; it does not crawl your site. Use a crawler, browser inspection, or server logs for a site-wide link audit. Google's link best practices explain how links can be made discoverable.

8. Check mobile usability and Core Web Vitals#

Try representative pages at narrow and wide viewport sizes, with a keyboard and with zoom enabled. Check that navigation, labels, text, and interactive elements remain usable. Use PageSpeed Insights to inspect available field data and lab diagnostics; field data represents real visits, while lab tests are useful for reproducing problems and do not replace real-user measurement.

For Core Web Vitals, Google recommends evaluating the 75th percentile of visits separately for mobile and desktop. The good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 (S5). For example, if the largest image loads late, inspect its size, delivery priority, and server response before changing the page. For layout shifts, reserve space for images and embeds. Retest the affected template and monitor field data as it accumulates. A favorable score does not guarantee search performance.

9. Verify structured data and metadata#

Check that titles and descriptions accurately describe each page and that important information is visible in the rendered content. Display in search results varies; avoid treating a fixed character count as a guaranteed cutoff.

Where structured data is appropriate, compare it with the visible page and validate it with the Rich Results Test. Google's structured data guidelines explain that valid markup does not guarantee a rich result. Our schema implementation guide walks through an example and the checks to make before publishing.

10. Prioritize, verify, and monitor#

Record each issue with an example URL, evidence, intended behavior, impact, owner, and a way to verify the fix. A broken template affecting many important pages generally deserves attention before a cosmetic issue on one low-traffic page. After release, repeat the same requests and live tests, then monitor indexing and Search Console trends over comparable periods. Allow for reporting delays, seasonality, and other site changes when interpreting results.

Choose tools according to the task and current product details. Our software reviews and comparison guides can help you research options; confirm current features and pricing with each provider.

Sources#

• S1: Google Search Central: Introduction to robots.txt
• S2: Google Search Central: Block indexing with noindex
• S3: Google Search Central: Sitemaps overview
• S4: Google Search Central: Consolidate duplicate URLs
• S5: web.dev: Web Vitals

Last updated: October 28, 2026.