Technical SEO Audit Checklist: The Checks Your Crawler Should Run Every Week

The traditional technical SEO audit is a project. Someone runs a crawl, spends two weeks writing a sixty-page document, presents it, and the development team fixes the top ten items over the following quarter. Then everyone moves on.

The problem is that the site keeps changing. The week after the audit lands, a template edit strips the canonical tag from every product page. A month later, a redirect rule starts sending an entire category to the homepage. The audit is out of date before its fixes are even deployed.

Technical SEO is not a document. It is a set of conditions that must stay true, and the only way to keep them true is to check them constantly. Here is the checklist we run weekly on every site we care about, and why each item is on it.

Why a weekly crawl beats an annual audit

An audit tells you the state of the site on one day. A weekly crawl tells you what changed, and change is what causes most technical SEO damage.

Think about the failures that actually cost traffic: an accidental noindex on a section, a robots.txt rule that blocks a directory, a migration that leaves thousands of 404s, a staging site that goes live with its "disallow all" intact. None of these are subtle once you look. All of them are invisible if nobody does.

Weekly is short enough to catch a bad deployment before Google has fully processed it, and long enough for a crawl of a large site to finish in between. Add an extra crawl after any major release or migration.

The other advantage of a recurring crawl is the comparison. A single crawl with 4,000 issues is overwhelming. A crawl showing 40 new issues since last week is a to-do list.

Crawlability: status codes, robots.txt, and redirects

Start with whether search engines can reach your pages at all.

Every URL in the crawl should return a 200, a deliberate 301, or a deliberate 404 or 410. Flag anything else. 5xx responses mean server trouble. 302s where you meant 301s send a signal you did not intend. Soft 404s, where a missing page returns a 200 with a "not found" message, waste crawl budget and confuse indexing.

Fetch robots.txt on every crawl and compare it with the previous version. A robots.txt edit is one of the highest-impact changes anyone can make to a site, and it is routinely made by people who do not know that.

Look for redirect chains and loops. Every extra hop slows crawlers and browsers and adds another chance for something to break. Fix chains at the source so each old URL points directly to its final destination.

Indexability: canonicals, noindex, and sitemaps

A page can be perfectly crawlable and still never appear in search.

Check every indexable page for a self-referencing canonical, and flag any canonical pointing at a URL that redirects, is noindexed, or returns an error. Canonical mistakes propagate: one bad template can decanonicalise an entire content type.

List every page carrying a noindex directive, whether in a meta tag or an HTTP header, and compare against last week. New noindexes on pages that earn traffic are almost always accidents.

Reconcile three lists: pages found by the crawl, pages in the XML sitemap, and pages Google reports as indexed in Search Console. Sitemap URLs that redirect, error, or carry a noindex tell Google the sitemap cannot be trusted.

If you serve multiple languages or regions, validate hreflang on every crawl. Every tag needs a return tag, every target must be indexable, and the language and region codes must be valid. Hreflang breaks quietly and often.

On-page signals: titles, descriptions, headings, and duplicates

Titles and descriptions are the oldest checks in SEO and still among the most neglected.

Flag missing, duplicate, and over-long title tags. Duplicates matter most: a hundred pages sharing the title "Products" is a template problem, and fixing the template fixes all hundred. Do the same for meta descriptions, remembering that Google often rewrites them, so treat this as a click-through task rather than a ranking task.

Check for pages with no H1, multiple H1s, or an H1 that does not describe the page. Check for thin pages with very little text, and for near-duplicates where the main content is essentially identical. Faceted navigation, print versions, and tracking parameters are the usual suspects.

Where you use structured data, validate it on every crawl. Broken markup will not hurt rankings directly, but it costs you the rich results you added it for.

Architecture: internal links, crawl depth, and orphan pages

How pages link to each other determines how authority flows and how easily crawlers find new content.

Look at crawl depth, meaning how many clicks from the homepage each page sits. Important pages buried five or six clicks deep are telling Google they are unimportant.

Find orphan pages: URLs that exist in your sitemap or analytics but receive no internal links. They can still be indexed, but they are the pages most likely to drift out of the index and least likely to rank.

Check for broken internal links and internal links pointing at redirects. Both are pure waste and both are trivial to fix once you have the list.

Performance, Core Web Vitals, and rendering

Google's Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Google publishes the thresholds it considers good: LCP within 2.5 seconds, INP within 200 milliseconds, and CLS at or below 0.1.

A crawler gives you lab measurements for every page, which is the fastest way to find templates with problems. Search Console's Core Web Vitals report gives you field data from real users, which is what actually counts. Use the crawl to find the cause and Search Console to confirm the effect.

Beyond the three vitals, check for oversized images, uncompressed responses, and pages whose main content depends on JavaScript. If your crawler renders JavaScript, compare rendered and unrendered versions of key templates. Content that appears only after rendering may be indexed late or not at all.

The weekly checklist

Here is the full list in one place. Severity is a starting point; adjust it for your own site.

Triage: turning findings into a fix list

A crawl will always find something. The skill is deciding what to do about it.

Sort by two questions. Does this stop pages being crawled or indexed? Does it affect pages that earn traffic or revenue? Yes to both goes to the top and gets fixed this week. No to both goes into a backlog you review quarterly.

Group issues by template rather than by URL. Ten thousand missing canonicals is one ticket for the developer who owns the product template, not ten thousand tickets. Write tickets with example URLs, expected and actual behaviour, and the business reason.

When the fix ships, recrawl. Do not close the ticket on the developer's word. Close it when the crawl confirms the issue count has dropped to zero. With LiveSolN the crawler runs these checks on a schedule across up to a million pages per site, so the weekly comparison arrives without anyone remembering to start it.

Key takeaways

• Technical SEO is a set of conditions to keep true, not a report to write once a year.
• Crawl weekly and read the comparison; new issues since the last crawl are your to-do list.
• Crawlability and indexability come first, because nothing else matters if the page cannot be indexed.
• Group findings by template, write tickets developers can act on, and close them only when a recrawl confirms the fix.

LiveSolN was built by SEOs who ran this checklist by hand for years, and it now runs every one of these checks automatically so your time goes into the fixes.