How to run a technical SEO audit

A technical SEO audit should tell you what blocks discovery, crawling, rendering, indexing, and a stable user experience. It should also tell you what is working. A list of 4,000 warnings does neither. The useful audit connects each finding to a page, shows the evidence, explains the risk in plain words, and gives the execution team a testable next step.

This guide gives you that process. You will set a safe crawl scope, run eight focused review passes, separate template problems from page exceptions, and finish with a verification plan. The examples use LLMIC, but the evidence rules apply to any crawler or audit workflow.

The one-page audit brief to write before you crawl

Do not begin with the Run button. Begin with a brief. A crawler cannot know which pages make money, which subdomains are owned by another team, whether staging is public by mistake, or whether a blocked filter URL is intentional. Ten minutes of scope work can prevent hours of noisy review.

Set limits that match the site

Confirm whether the site allows crawling and whether the server can handle your planned concurrency. Use a conservative speed for an unfamiliar host. Include query parameters only when they represent useful pages. Decide whether to follow redirects, crawl external links for status, render JavaScript, read sitemaps, and import Search Console URLs. Save these settings with the audit.

For a large site, do not assume crawl budget is the first problem. Google says its dedicated crawl-budget guidance mainly matters for very large or rapidly changing sites. Most teams should first find wasted URL patterns, failed responses, conflicting index signals, and weak internal discovery.

The eight-pass technical SEO audit

Run the passes in this order. Each pass depends on evidence from the one before it. A failed HTML response should not become five separate content warnings. Transport comes first.

Pass 1: Confirm access and transport

Start with the requested URL, final URL, HTTP status, response time, MIME type, and redirect hops. Separate successful HTML documents from redirects, client errors, server errors, timeouts, blocked requests, and non-HTML files. Retry uncertain failures before calling them broken.

• Review 4xx and 5xx responses with the exact source page that links to them.
• Find redirect loops, long chains, mixed HTTP/HTTPS hops, and redirects to an unrelated destination.
• Check whether important CSS, JavaScript, image, and API resources are blocked or failing.
• Look for soft-404 templates only after confirming a successful 2xx response.

Do not run title, H1, schema, or thin-content checks on a failed response. The server did not provide a valid page to audit. Report the transport problem once and preserve the source-link evidence needed to repair it.

Pass 2: Test crawl and index controls

Now review robots.txt, meta robots, X-Robots-Tag headers, login requirements, and canonical targets. A crawler being allowed to request a URL does not mean the URL is indexable. A noindex directive cannot be read if robots.txt prevents the crawler from fetching the page.

Build four groups: indexable, intentionally excluded, conflicting, and unavailable. The conflicting group deserves attention. Examples include an indexable page that canonicals to a noindex URL, a sitemap URL blocked by robots.txt, or a valuable landing page with an accidental noindex header.

Pass 3: Reconcile canonical signals and duplicates

For each important template, compare the final URL, self-referential canonical, redirect behavior, sitemap inclusion, internal links, and language annotations. Google describes redirects and rel=canonical as strong signals, while sitemap inclusion is weaker. These signals work best when they agree.

Do not treat every duplicate as a penalty. Product filters, tracking parameters, print pages, and regional variants can create legitimate URL variants. Decide which URL should represent the content. Then align links, canonical tags, redirects, and sitemap entries with that decision.

Pass 4: Measure discovery and site structure

A sitemap can introduce URLs, but it cannot replace internal links or guarantee indexing. Build the measured link graph from confirmed source pages. For each important target, keep the source URL, visible anchor, target, status, and document layer. Imported URLs and sitemap-only URLs are candidates, not proof of an internal link.

• Find important pages with no confirmed internal source.
• Find deep pages that require too many useful clicks from an entry point.
• Find navigation that disappears on mobile or after rendering.
• Find repetitive anchors that do not explain the destination.
• Find high-value pages reached mainly through redirects.

Pass 5: Compare source HTML with the rendered page

Google processes JavaScript pages through crawling, rendering, and indexing. Keep the initial HTML and rendered DOM separate. Check whether the title, canonical, robots directives, H1, main copy, structured data, and internal links exist in each layer. Record the render wait and any important network or console failure.

A visible browser page does not prove the initial response contained the same evidence. It also does not prove every crawler can execute the scripts. When essential content appears only after a fragile client request, describe the exact dependency instead of writing the vague finding ‘JavaScript SEO issue.’

Pass 6: Review page meaning and metadata

Only successful HTML pages belong in this pass. Check whether the title, main heading, description, headings, body, image alternatives, language, and structured data describe the same purpose. Review duplicates by template and intent. A repeated legal heading may be harmless; a repeated product title across distinct products may not be.

For headings, build the actual H1–H6 tree. Look for an unnamed heading, multiple competing main headings, and level jumps that hide relationships. Do not change a heading level only to make text smaller. Styling belongs in CSS; heading levels describe document structure.

Pass 7: Check real user performance

Use field data when it is available and keep device and page-group context. Google’s current ‘good’ Core Web Vitals thresholds are LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. These values describe loading, responsiveness, and visual stability. A single lab run is diagnostic evidence, not proof of field performance.

Group similar pages before assigning work. A slow hero image on a product template needs a different owner from a third-party script that blocks every page. Save the measured element or interaction with the task so the next person does not have to rediscover it.

Pass 8: Prioritize, assign, and verify

Priority is not the warning color. Use evidence confidence, affected important pages, user or search impact, implementation effort, and blast radius. A confirmed 500 response on checkout-supporting pages usually deserves attention before 200 slightly long descriptions.

A worked audit example

Assume a crawl contains 1,200 URLs. This is an illustrative example, not a customer result. The first pass finds 36 redirects, 14 client errors, 4 server errors, and 22 URLs that failed because the crawl was interrupted. The 22 interrupted rows remain unavailable. They are not counted as broken pages.

The canonical pass finds 180 filter URLs pointing to 12 category pages. That may be intentional. The auditor samples the filters, checks internal links and sitemap inclusion, and confirms that only the 12 categories should be indexed. The action is not ‘fix 180 canonicals.’ It is ‘remove filter URLs from the sitemap and stop internal navigation from generating the unwanted combinations.’

The rendering pass finds that article links exist in the rendered menu but not in source HTML. They load reliably in tests, so the auditor records a dependency rather than a failure. A separate test shows the product H1 disappears when one API call times out. That is a confirmed rendering risk with an exact failure condition. These two JavaScript observations should not receive the same recommendation.

What the final audit should look like

Lead with a one-page decision summary. Show what you checked, what you could not check, the three most important confirmed risks, and the next verification date. Then provide a table of reviewed tasks. Keep raw crawl exports as supporting evidence rather than the main report.

1. State the affected page or template.
2. Show the exact retained evidence and observation date.
3. Explain the user or search risk without promising an outcome.
4. Name the smallest safe change and its owner.
5. Name the reviewer and any rollback condition.
6. Define the fresh check that will confirm or reject the fix.

After deployment, repeat the same detector on the same page set. Preserve exclusions and unavailable rows. If the technical condition changes but traffic does not, report both facts. The fix may be correct while demand, relevance, competition, seasonality, or other systems continue to affect performance.

Where LLMIC fits

In LLMIC, begin with a bounded crawl and keep the active crawl visible while you review findings. Open affected pages rather than relying on totals alone. Move confirmed work into the Action Queue, review proposed changes, and save a fresh crawl after release. Exports should carry the URL, evidence, recommendation, and verification state so another person can understand the task outside the app.

LLMIC does not publish changes to your website merely because a recommendation exists. Treat preparation, review, implementation, and verification as separate steps. Optional provider connections use their own scope and freshness rules, so keep their observations separate from crawl facts.

Sources and measurement notes

• Google Search Central: crawling and indexing overview
• Google Search Central: canonical URL methods and signal strength
• Google Search Central: JavaScript crawling, rendering, and indexing
• Google Search Central: Core Web Vitals definitions and thresholds
• Google crawling infrastructure: crawl-budget guidance
• Ubersuggest, India, English: the broader seed “technical SEO audit” was checked on 28 September 2026. About 320 monthly searches and difficulty 16/100 are cluster context, not a forecast for this page.

Frequently asked questions

Run the next useful check

If you have not run a crawl yet, start with the first-audit documentation and save the scope before pressing Run. If you already have findings, choose one important template and apply the eight-pass review above before creating a bulk task.

Run your first website audit · Understand audit results · Use the technical SEO audit checklist · Compare LLMIC plans