Technical SEO Audit: 15 Checks I Run on Every Site

A technical SEO audit can prove what a crawler, browser, server response and selected Google reports show at a documented moment. It cannot prove that a fix will produce rankings, traffic, indexing or rich results. Start with access and response evidence, separate crawlability from indexability, compare source HTML with rendered HTML, then prioritize only issues that affect valuable page types. The fifteen steps below are my audit workflow, not Google’s official checklist or ranking formula.

What a technical SEO audit actually proves

Google Search’s technical requirements identify minimum eligibility conditions such as accessible crawling, a successful response and indexable content, while explicitly stating that eligibility does not guarantee indexing. An audit can confirm whether selected URLs meet observable conditions and where signals conflict. It cannot certify Google’s future canonical choice, indexing decision or search performance.

Evidence layer	What it can establish	What it cannot establish	Audit decision	Owner
Server response	Observed status, headers, redirect target and latency at test time	Future crawl or indexing outcome	Repair broken or misleading responses on valuable URLs	Engineering
Crawler access	Whether tested rules and authentication allow the chosen user agent	That every search crawler will behave identically	Remove accidental blocks or document intentional ones	Platform
Rendered page	Content, links and directives visible after execution	That Google rendered the same version at another time	Compare source and rendered output on representative templates	Frontend
Search Console	Google-recorded examples and property-level report boundaries	A complete crawl log or indexing promise	Use examples to form a reproducible URL test set	SEO
Site architecture	Observed links, depth and disconnected URL sets	That a link alone causes indexing or ranking	Connect valuable pages through useful crawlable links	Content and engineering

Verify the template claim before using it in the title

A checklist inside an article is not a downloadable file. Keep the embedded table editable in WordPress, copy it into your own working document if useful, and add real observations only. The visible title and metadata make no download offer; the original workbook wording remains only in the production audit so the change is traceable.

The 15-step technical SEO audit checklist

This sequence is an author-defined operating order. Start with conditions that can invalidate later evidence, then move from discovery and access to indexing signals, rendering, enhancements and prioritization. On a very small or specialized site, some checks may be not applicable; document that decision rather than forcing a finding.

No.	Check	Evidence to collect	Output	Boundary
1	Scope page types	Template inventory, host and environment	Representative URL set	Do not claim complete coverage from a partial sample
2	Verify responses	Status, headers and body agreement	Response ledger	Separate real errors from soft-error content
3	Review robots.txt	Allowed and disallowed paths plus blocked resources	Rule-to-URL test	Do not treat robots.txt as deindexing
4	Review index directives	robots meta and X-Robots-Tag	Directive matrix	Blocked crawling can hide noindex from Google
5	Compare canonicals	Declared, redirected, sitemap and observed Google choice	Canonical cluster sheet	A declaration is a signal, not a guarantee
6	Trace redirects	Source, chain, target and status semantics	Redirect map	Preserve the intended destination and avoid loops
7	Check sitemap entries	Canonical, successful, intended URLs only	Sitemap exception list	Submission does not guarantee indexing
8	Map internal links	Crawlable links to valuable pages	Orphan and depth review	Navigation should reflect reader journeys
9	Review pagination and facets	Unique paths, links, parameters and duplicate sets	Pattern decision log	Do not index every generated combination
10	Compare source and rendered HTML	Main content, links, directives and resources	Rendering difference record	Do not infer from a screenshot alone
11	Group duplicate URLs	Protocol, host, case, parameters and near-duplicates	Duplicate cluster map	Choose consistent signals per cluster
12	Validate structured data	Visible-content match and feature requirements	Error and eligibility record	Markup does not guarantee rich results
13	Review page experience evidence	Field data where available and reproducible lab diagnostics	Performance issue brief	Do not promise ranking changes from one metric
14	Read Search Console boundaries	URL Inspection, Page Indexing and Crawl Stats	Google-evidence worksheet	Examples and reports are not exhaustive
15	Prioritize and assign	Severity, affected pages, business value, confidence and effort	Owned implementation queue	Record what to verify after release

Crawl access: robots.txt, status codes and blocked resources

Google’s robots.txt guidance says robots.txt manages crawler access and is not a mechanism for keeping a web page out of Google. Google’s HTTP status documentation distinguishes successful responses, redirects, client errors and server errors, while noting that a successful response does not guarantee indexing. Record the response body as well as the code so soft-error pages are not mistaken for healthy content.

Condition	Direct evidence	Likely risk	First action	Do not conclude
Important URL disallowed	Parsed rule and exact URL test	Googlebot cannot fetch the page body	Confirm intent and remove accidental rule	That the URL is automatically removed from results
Essential resource blocked	Rendered difference and blocked request	Content or layout may be misunderstood	Allow the needed resource or render essential content server-side	That every blocked asset is harmful
Error-like body on success response	Response body, template and internal links	Soft-error classification or poor user outcome	Return useful content or an appropriate status	That the code alone proves health
Redirect chain	Hop-by-hop status and final body	Delayed discovery, loops or wrong target	Redirect directly to the durable destination	That every extra hop causes a ranking loss
Persistent server errors	Server log and Crawl Stats trend	Reduced crawl activity and unavailable content	Stabilize serving and monitor recovery evidence	A fixed date for recrawl or recovery

Indexability: noindex, canonicals, duplicates and URL signals

Google’s canonicalization documentation describes redirects and canonical tags as stronger signals and sitemap inclusion as a weaker signal, while Google ultimately selects the canonical. Compare declared canonical, redirects, internal links, sitemap entries and the Google-selected canonical from indexed evidence. A disagreement is a diagnosis prompt, not automatic proof that one tag is broken.

Layer	Evidence	Conflict example	Safe repair	Verification limit
Index directive	Rendered meta robots or response header	Valuable page returns noindex	Remove only after confirming intended search state	Recrawl and indexing timing are not guaranteed
Declared canonical	Final rendered canonical URL	Page points to a non-equivalent destination	Choose the closest durable equivalent	Google may select another canonical
Redirect	Server response and final target	Canonical points one way and redirect another	Align the cluster on one durable destination	Processing time varies
Internal links	Crawlable href targets	Navigation favors parameter duplicates	Link consistently to the preferred URLs	Links are signals, not commands
Sitemap	Submitted canonical URL set	Duplicate or redirected URL remains listed	Keep intended canonical successful URLs	Sitemap inclusion does not ensure indexing

Sitemaps and discovery: useful hints, not indexing guarantees

Google’s sitemap overview states that a sitemap can help discovery but does not guarantee crawling or indexing. The build-and-submit guidance explains supported submission routes. Audit the sitemap as an intended canonical inventory: successful URLs, current modification data where trustworthy, no redirects, no blocked or noindex entries, and consistent host/protocol choices.

Rendering and JavaScript SEO

Google’s JavaScript SEO basics describe crawling, rendering and indexing as distinct phases and explain that blocked pages or resources are not rendered. Compare the initial response and rendered DOM for main content, crawlable links, canonical tags, robots directives and structured data. A browser screenshot is useful for visual review but is not sufficient evidence of the HTML and link state available to a crawler.

Internal links, pagination and orphan-page risk

Google’s crawlable-link guidance supports standard links with resolvable destinations. Build a graph from actual links, not only sitemap URLs. A page is operationally orphaned when the audit cannot reach it through the intended site journey, even if a sitemap lists it. Review pagination and facets by pattern: reader value, unique content, crawlable path, canonical intent and parameter behavior.

Pattern	Evidence	Keep accessible when	Consolidate or block when	Owner
Category pagination	Crawlable next-page links and unique item sets	Users need continued discovery	Pages repeat or create broken sequences	Frontend and SEO
Filter or facet	Demand, unique selection and stable URL rules	The combination serves a distinct task	Combinations multiply without user value	Product and engineering
Orphan landing page	No internal path but intended search role	A relevant hub can link naturally	The page is obsolete or duplicates another	Content
JavaScript navigation	Rendered anchor links with real destinations	Links exist without user-only event handling	Important destinations remain undiscoverable	Frontend
Parameter duplicate	Same content under tracking or sort parameters	Parameter has a necessary distinct function	Signals fragment across equivalent URLs	Engineering

Structured data and rich result limits

Google’s structured-data introduction explains how markup can make a page eligible for supported search features, while appearance is not guaranteed. Audit feature relevance, required properties, visible-content agreement, canonical placement and errors. Remove fabricated ratings, prices, authors, availability or other properties rather than filling them to satisfy a validator.

Finding	Evidence required	Treatment	Owner	Do not claim
Invalid required property	Official feature documentation and tested markup	Correct the source data or remove inapplicable markup	Development	That validation earns a rich result
Markup not visible on page	Rendered page and JSON-LD comparison	Align markup to visible content	Content and development	That hidden claims are acceptable
Wrong page type	Page purpose and feature eligibility	Use only the matching supported type	SEO	That more schema is better
Duplicate markup layers	Theme, plugin and custom output inventory	Choose one governed source	Platform	That duplicates always cause a penalty
Valid but no enhancement	Test result and Search Console evidence	Keep accurate markup; monitor without promises	SEO	That absence proves a defect

Search Console evidence: URL Inspection, Page Indexing and Crawl Stats

URL Inspection documentation states that a valid live test does not guarantee indexing and does not test every condition. Page Indexing guidance provides property-level status groupings and examples but may omit URLs unknown to Google. Crawl Stats documentation describes aggregated Google crawling history and representative example URLs, not a complete server log.

Surface	Useful evidence	Important boundary	Best use	Record
URL Inspection indexed view	Last indexed evidence and Google-selected canonical	Not live; not a ranking promise	Diagnose a specific representative URL	URL, view type, crawl time and result
URL Inspection live test	Current fetch and rendered test evidence	Does not test every indexing condition	Verify a deployed technical change	Test time, response and rendered details
Page Indexing	Grouped indexed and non-indexed states	Unknown URLs may be absent; examples are limited	Find patterns by page type	Property, date, reason and sampled URLs
Crawl Stats	Requests, response groups and host availability	Aggregated and not a full log	Investigate serving or crawl shifts	Property scope, period and host
Server logs	Requests observed by your infrastructure	Not Google’s indexing decision	Validate crawl paths and responses	Retention window, bot validation and URL

Prioritization: severity, confidence, business impact and fix effort

technical_seo_priority = severity × affected_pages × business_value × fix_confidence / implementation_effort. Severity is the technical consequence if confirmed; affected_pages is the verified page-type scope, not a guessed crawl total; business_value is the importance of that page type; fix_confidence is confidence in diagnosis and repair; implementation_effort is delivery and regression cost. This is an audit prioritization formula, not a Google ranking formula.

Priority input	High value means	Evidence needed	Adjustment	Stop condition
Severity	Access, response or directive blocks a valuable page role	Reproducible URL-level failure	Reduce when issue is cosmetic or intentional	Intended state is undocumented
Affected pages	Pattern appears across a confirmed template set	Inventory query and representative tests	Do not extrapolate from one URL	Scope cannot be reproduced
Business value	Page type supports an important user or product journey	Named owner and page role	Separate importance from current traffic	No accountable business owner
Fix confidence	Cause and bounded repair are understood	Before state, proposed change and test	Lower for ambiguous canonical or indexing outcomes	Repair depends on folklore
Implementation effort	Change, QA and rollback are manageable	Engineering estimate and dependency map	Increase for platform-wide regression risk	No rollback or release owner

Weak audit versus stronger audit

Layer	Weak audit	Stronger audit	Why stronger	Measurement limit
Finding	“Thousands of crawl errors” from a tool label	Named URL pattern with response and intended state	Makes the issue reproducible	Sample does not prove total scope
Conclusion	“Blocked pages cannot be indexed”	robots.txt blocks fetching; index state needs separate evidence	Separates crawlability from indexability	Future processing is unknown
Canonical	“Google ignored the canonical”	Cluster has conflicting redirect, link and sitemap signals	Identifies repairable signal conflict	Google selection remains its decision
JavaScript	“Google cannot render the site”	Representative template loses main links in rendered test	Defines page type and missing output	Test environment is time-bound
Recommendation	“Fix all warnings”	Prioritized owned queue with verification and rollback	Connects work to risk and value	No ranking outcome is promised

Detailed operational example

Assume an ecommerce site has category pages that appear in the sitemap but are absent from the intended navigation after a frontend release. Some sampled pages also declare a canonical to the first category page, while product links are created only after a user interaction. This is a hypothetical operating example, not a crawl report, case study or claim about results.

Stage	Starting issue	Evidence collected	Affected page types	Weak conclusion	Stronger conclusion	Exact fix plan	Owner	Expected observation	Do not claim
Scope	Category discovery appears inconsistent	Template inventory and sampled URLs	Category and product-list pages	“Google stopped crawling”	Navigation and canonical signals conflict on the tested template	Restore crawlable category links and correct template canonical	Frontend lead	Rendered links and self-consistent canonicals on test set	Guaranteed indexing
Access	No intentional robots block found	robots.txt parser and exact URL tests	Category pages	“robots.txt is fine, so indexing should work”	Access is only one eligibility layer	Keep rule unchanged and document result	SEO	Crawl remains allowed in retest	Ranking recovery
Rendering	Product links require interaction	Source/rendered HTML and event behavior	Product-list pages	“JavaScript is bad for SEO”	Important links are absent from the tested rendered state	Output standard anchors in rendered HTML	Frontend lead	Links present without interaction	A fixed crawl date
Canonical	Category pages point to first page	Rendered canonical and URL cluster	Paginated categories	“Canonicals are ignored”	Template emits an unintended consolidation signal	Apply intended canonical logic and regression tests	Platform engineer	Declared signals match page role	Google-selected canonical outcome
Verification	Release is complete	Live test, rendered comparison and change log	Changed templates	“Issue fixed”	Implementation evidence passes; Google processing remains separate	Recheck selected reports and server evidence over time	SEO and engineering	Technical state remains stable in repeated tests	Traffic or revenue increase

What to remove, rewrite or keep audit-only

Treatment	Use when	Example	Required evidence	Owner
Remove	A claim is false or unsupported	“Submitting this sitemap gets every URL indexed”	Official boundary and old wording	Editor
Rewrite	The diagnosis overstates the evidence	“Google cannot render JavaScript” becomes a template-specific finding	Saved source/rendered comparison	SEO
Audit-only	A hypothesis is useful but not yet proven	Possible crawl shift without validated logs	Test plan and verification status	Analyst
Keep	The statement is directly supported and bounded	robots.txt controls crawler access, not deindexing	Visible official source	Editor
Escalate	Fix carries platform-wide regression risk	Canonical template or routing change	Owner, staging test and rollback	Engineering lead

Common technical SEO audit mistakes

Common mistakes include treating every warning as urgent, using robots.txt for removal, calling sitemap submission an indexing fix, confusing a live inspection with an index promise, counting every generated URL as valuable, changing canonicals without mapping a cluster, judging rendering from a screenshot, adding schema that does not match visible content, fixing Core Web Vitals in isolation, and closing a ticket without a post-release evidence check.

FAQ

Does a sitemap guarantee indexing?

No. Google’s sitemap documentation describes a sitemap as a discovery aid and explicitly says it does not guarantee that listed items will be crawled or indexed. Use the file to declare intended canonical URLs and make discovery easier, then inspect whether entries are successful, current and internally supported. Diagnose indexing separately through representative URL evidence, Page Indexing patterns and content quality; do not report submission itself as a completed indexing fix.

Can robots.txt remove a URL from Google?

Not reliably. Google documents robots.txt as a crawler-access control, not a mechanism for keeping a web page out of Search. A blocked URL can still be known and may appear without a description because Google cannot fetch its content. For removal intent, choose an appropriate supported method such as noindex while allowing crawling, password protection for private content, or a correct status response, depending on the page’s real purpose.

Is URL Inspection proof that Google will index the page?

No. The indexed view reports what Google knows about a URL, while the live test checks a current fetch against only some conditions. Google’s documentation states that a valid live result is not an indexing guarantee and cannot test every possible issue, including some duplicate and canonical states. Save the view type, test time and result, then combine it with page-level evidence and property reports without predicting a processing date.

Does schema guarantee rich results?

No. Correct structured data may make a page eligible for a supported search feature when the markup matches visible content and all relevant requirements are met. Eligibility is not a display promise. Validate the appropriate feature, remove properties you cannot support, and check Search Console evidence where available. Keep accurate markup even when no enhancement appears, but never sell validation or schema installation as guaranteed rich-result visibility.

Should every technical issue be fixed immediately?

No. Some findings describe intentional exclusions, low-value generated URLs, harmless implementation differences or evidence too weak for a safe change. Prioritize confirmed issues by severity, affected page types, business value, fix confidence and implementation effort. Require an owner, rollback path and recheck method. A low-confidence change to routing or canonical templates can create more risk than a well-documented issue that remains in the audit queue.

What should I check first in a technical SEO audit?

Begin with scope and the technical conditions that can invalidate later observations: representative page types, response status, crawler access, index directives and the actual rendered content. Then compare canonical, redirect, sitemap and internal-link signals before reviewing enhancements. Use Search Console as bounded Google evidence, not as the only crawler. The first repair should be the highest-value reproducible defect with a clear owner and safe verification plan, not the largest tool warning count.

What I would fix first

I would first fix any confirmed access, response or directive defect that prevents a valuable page type from serving its intended public content. Next I would align canonical, redirect, sitemap and internal-link signals for the same URL cluster. Rendering defects come next when main content or crawlable links are missing. Enhancements and lower-risk cleanup wait until the foundational state is reproducible, owned and safe to release.