Back to Blog
Technical SEO

A Day Spent Auditing Technical SEO

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

Terry Hunt
August 23, 2026
6 min read

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.

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.

Inventory routes and sources

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.

I normalize case, trailing slashes, parameters, and tag names before comparing sets. Duplicate-looking URLs often begin as inconsistent normalization.

Check crawl and index controls

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.

I separate authored routes from platform noise and protected paths. Blocking a crawler is different from removing an already indexed URL.

Inspect rendered metadata

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.

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.

Validate structured data

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.

Schema warnings become prioritized by user and search impact. Adding more schema types is not a substitute for correcting the page.

Review links and performance risks

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.

Slow routes receive a measured follow-up for cache, backend, or rendering traces. The audit records the hypothesis and missing evidence.

Turn findings into work

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.

  • Route sources are mapped.
  • Crawl signals agree.
  • Metadata and headings render correctly.
  • Schema matches visible content.
  • Priorities name one next action.

Need help putting this into practice?

Terry Hunt Dev provides technical SEO services for sites with crawl, rendering, schema, or performance problems. Request an evidence-based audit through the contact page.

Enjoyed This Article?

Get more tutorials and insights delivered to your inbox. No spam, just valuable content for web developers.