<p>I start a technical SEO audit by building an inventory of public routes and their publication sources. Without that map, a crawl can find symptoms while missing the code or CMS rule that creates them. I compare static routes, generated pages, CMS records, sitemap entries, and redirects.</p><p>A one-day audit produces evidence and priorities. Search performance and field data may require follow-up because they come from external systems and longer time windows.</p>

<h2>Inventory routes and sources</h2>

<p>I collect routes from the application, CMS, sitemap, navigation, and known inbound paths. Each route gets a page type, source, expected status, canonical rule, and intended index state.</p><p>I normalize case, trailing slashes, parameters, and tag names before comparing sets. Duplicate-looking URLs often begin as inconsistent normalization.</p>

<h2>Check crawl and index controls</h2>

<p>I request robots.txt, sitemap files, representative pages, and redirects. I inspect HTTP status, X-Robots-Tag, meta robots, canonical, and sitemap membership together. Those signals should describe one policy.</p><p>I separate authored routes from platform noise and protected paths. Blocking a crawler is different from removing an already indexed URL.</p>

<h2>Inspect rendered metadata</h2>

<p>For each page type I check one title, description, canonical, Open Graph fields, Twitter fields, H1, and semantic heading order. Dynamic pages receive samples for missing and unusually long values.</p><p>I compare server HTML with the rendered page when JavaScript or CMS hydration can change content. A CMS field existing does not prove it reached the head.</p>

<h2>Validate structured data</h2>

<p>I parse JSON-LD, check supported types, and compare names, descriptions, URLs, dates, authors, and FAQs with visible content. Generated identity facts should override stale CMS copies.</p><p>Schema warnings become prioritized by user and search impact. Adding more schema types is not a substitute for correcting the page.</p>

<h2>Review links and performance risks</h2>

<p>I find broken internal links, orphaned routes, redirect chains, and navigation that points at noncanonical URLs. I sample server response time and Core Web Vitals evidence without claiming one lab run represents field performance.</p><p>Slow routes receive a measured follow-up for cache, backend, or rendering traces. The audit records the hypothesis and missing evidence.</p>

<h2>Turn findings into work</h2>

<p>I group findings by root cause and create tasks with affected templates, evidence, desired behavior, and validation. One shared metadata bug becomes one implementation card, not fifty page cards.</p><ul><li>Route sources are mapped.</li><li>Crawl signals agree.</li><li>Metadata and headings render correctly.</li><li>Schema matches visible content.</li><li>Priorities name one next action.</li></ul>

<h2>Need help putting this into practice?</h2>

<p>Terry Hunt Dev provides <a href="/services/technical-seo">technical SEO services</a> for sites with crawl, rendering, schema, or performance problems. Request an evidence-based audit through the <a href="/contact">contact page</a>.</p>

Follow my technical SEO audit process for inventorying routes, checking crawl and index rules, validating metadata and schema, and prioritizing fixes.

Technical SEO Audit Process: A One-Day Checklist

Follow a technical SEO audit through route inventory, crawl controls, rendered metadata, structured data, internal links, and prioritized fixes.

Technical SEO Articles

A Day Spent Auditing Technical SEO

Explore Other Categories