A technical SEO audit is often treated as a long list of items to check: crawl errors, broken links, missing metadata, slow pages, duplicate content, and indexing problems. The trouble with this approach is that a checklist can tell you what to look for without helping you understand what actually needs fixing. For related troubleshooting, see our articles on broken link audits and canonical tag issues.
A website can have hundreds of technical warnings and still perform well in search. Another site may have only a handful of issues, but one of them could prevent important pages from being indexed. Counting errors alone does not reveal which problems deserve attention, how they affect other pages, or whether previous fixes have worked.
A more useful technical SEO audit starts with the website's purpose, examines how search engines discover and process its pages, and connects each finding to a practical decision. Instead of simply checking off tasks, the audit should establish what is happening, why it matters, what to do next, and how to verify the result.
This checklist is designed around that process. It combines technical checks with impact assessment, diagnostic questions, recommended actions, and a repeatable way to compare audit results over time. It is intended for SEO professionals, website owners, developers, and anyone responsible for maintaining a website's technical health.
The audit loop: from crawl to verified improvement
1. Start with the pages that matter, not the number of errors
Before running a crawler, establish which pages the website needs search engines to find. A technical issue affecting a high-value service page may deserve attention before dozens of minor warnings on old blog posts.
This first step creates a reference point for the entire audit. Without it, even a detailed crawl can produce a large report with little practical direction.
Checklist: Establish the audit baseline
Create a list of priority URLs
Divide the website into useful groups rather than treating every URL as equally important.
| Page group | Examples | What to establish |
|---|---|---|
| Business-critical | Main services, products, pricing | Availability, crawlability, indexing |
| Organic traffic drivers | Pages receiving search impressions and clicks | Current visibility and technical stability |
| Recently changed | Redesigned pages, migrated URLs, updated content | Whether changes introduced new errors |
| Supporting content | Guides, articles, FAQs | Internal links and discoverability |
| Utility pages | Login, cart, account, internal search | Whether they should be crawlable or indexable |
A small business website may have only a few dozen priority URLs. A large ecommerce site may have thousands. The purpose of this exercise is to establish which parts of the website need the closest attention.
Audit question: If a technical problem appeared tomorrow, which pages would you investigate first, and what evidence would tell you that the problem had been resolved?
2. Check whether search engines can access the website
Crawling is the first stage in the search process. Search engines must discover and access pages before they can evaluate their content for indexing. Google describes crawling, indexing, and serving results as separate stages, so a successful crawl does not guarantee that a page will appear in search.
Access path: what the audit should follow
Checklist: Crawl access and server responses
Go beyond the status code
A URL returning HTTP 200 does not automatically mean it is working as intended. A server might return a success status while delivering an error message, an empty template, or an unintended page.
Likewise, a 404 response is not necessarily a problem. A permanently removed page with no useful replacement may appropriately return 404 or 410. The issue is whether the response matches the page's intended purpose.
| Finding | Diagnostic question | Recommended action |
|---|---|---|
| Unexpected 404 | Should this URL still exist? | Restore the page or redirect to a relevant replacement if one exists. |
| Unexpected 5xx | Is the issue isolated or widespread? | Check server logs, deployment history, and infrastructure. |
| Redirect chain | Can the destination be reached directly? | Update links and redirect the original URL to the final destination. |
| Soft 404 | Does the page display missing-content messaging despite returning 200? | Return an appropriate error status if the content is genuinely unavailable. |
| Blocked important URL | Is the restriction intentional? | Correct robots.txt or other access restrictions where necessary. |
| Unexpected HTTP version | Is the canonical HTTPS page accessible? | Correct redirects and internal references. |
A useful way to investigate an error is to trace it back to the page that links to it. For example, a broken internal link may appear to be a simple 404, but the actual source of the problem may be a navigation menu, a template, or an outdated redirect.
3. Audit the gap between discovered pages and intended pages
One of the most useful questions in a technical audit is not simply how many URLs a crawler found. It is whether those URLs represent the pages that the website actually intends to make available in search. If important pages are absent from the site's link structure, use our guide to finding and resolving orphan pages.
A crawler can discover thousands of URLs generated by filters, tracking parameters, sorting options, or internal search. Meanwhile, important pages may be absent because no crawlable links point to them.
The three-inventory method
A. Intended URLs
Pages the business wants users and search engines to find, including priority landing pages, products, services, and useful content.
B. Discovered URLs
Pages found through crawling, sitemaps, internal links, and other known URL sources.
C. Indexed URLs
Pages reported as indexed by Google Search Console, checked against the intended URL list and crawl results.
These inventories describe different things. Compare them rather than assuming they should contain identical URLs.
Checklist: URL discovery and coverage
Diagnose orphan pages by their importance
An orphan page is a page with no internal links pointing to it within the crawl's known link graph. It may still be discoverable through a sitemap or external links, but it is not well integrated into the site's internal structure.
Not every orphan page needs a fix. A temporary landing page or intentionally isolated utility page may be designed that way. The important question is whether the page is meant to be part of the website's discoverable content.
| Orphan page type | Suggested investigation |
|---|---|
| Important service page | Add a contextual link from a relevant service or navigation page. |
| High-value article | Link it from related articles, category pages, or a resource hub. |
| Old campaign page | Decide whether to retain, redirect, archive, or remove it. |
| Utility page | Confirm whether isolation is intentional. |
| Product or category page | Check category navigation, internal search, and product relationships. |
4. Audit indexing directives and canonical signals together
Indexing problems are particularly easy to misdiagnose when individual signals are checked separately. A page might return 200, be allowed in robots.txt, and have a canonical tag, but still not be indexed. For a focused checklist, see how to find and fix noindex issues.
The audit should check whether the site's signals agree about which pages are intended for search.
Canonical consistency test
noindexChecklist: Indexability
Build a canonical consistency test
For every priority URL, compare the following:
| Signal | Expected result |
|---|---|
| Requested URL | The page's intended public address |
| HTTP status | 200 for the live canonical page |
| Robots access | Allowed, unless there is a specific reason otherwise |
| Meta robots | No unintended noindex directive |
| Canonical tag | Points to the intended canonical URL |
| Sitemap | Includes the canonical URL if it is intended for indexing |
| Internal links | Prefer the canonical URL rather than alternate versions |
Special case: Similar pages that are not duplicates
Do not automatically canonicalize every page that looks similar.
For example, two product pages might share a template but represent different products. Two service pages may have similar descriptions but serve distinct locations. These pages require a review of their actual content, purpose, and intended search visibility before any consolidation decision is made.
5. Treat the XML sitemap as a statement of intent
A sitemap should represent the URLs a website wants search engines to discover. It is not a dump of every address the server can generate. For a more detailed troubleshooting workflow, read XML Sitemap Errors: Common Problems and Fixes.
A sitemap full of redirects, error pages, noncanonical URLs, and pages that are not intended for indexing can make the site's URL inventory harder to interpret.
Checklist: Sitemap quality
Find the difference between sitemap and crawl results
Consider a website with 1,200 URLs in its XML sitemap and 1,800 URLs discovered during a crawl. The difference of 600 URLs is not automatically an error.
The extra URLs could be:
- Parameterized versions of existing pages.
- Pagination or filtered navigation URLs.
- Redirecting legacy URLs.
- Duplicate URL variants.
- Useful pages that were not included in the sitemap.
- Unexpected URL patterns generated by the website's software.
The task is to classify the difference and determine whether each group has a valid purpose.
| Sitemap/crawl finding | URLs | Audit decision |
|---|---|---|
| Valid canonical pages | 1,080 | Retain |
| Redirecting URLs | 35 | Replace with final destinations |
| URLs returning 404 | 15 | Remove or restore where appropriate |
Blocked or noindex URLs | 20 | Investigate intent |
| Missing intended URLs | 50 | Review and add where appropriate |
| Parameterized URLs | 600 | Classify by function |
This kind of reconciliation is more useful than simply recording a sitemap error count.
6. Follow internal links from the source to the destination
Internal link auditing is often reduced to finding broken links. A more complete audit examines the relationship between the linking page, the destination, and the purpose of the link. Continue with our practical walkthrough on finding and fixing broken internal links.
A broken link on a critical navigation component may affect many pages. A broken link deep inside an old article may affect only a small part of the site. Both deserve investigation, but they are not necessarily equally urgent.
Checklist: Internal link health
Use inbound link impact to prioritize broken URLs
A broken URL's total inbound internal links can be more informative than its HTTP status alone.
For example, a broken destination linked from 35 different pages in the main navigation may warrant immediate attention. Another broken URL linked once from an obsolete article may be lower priority.
| Broken destination | Inbound internal links | Likely action |
|---|---|---|
/services/seo-audit | 42 | Investigate immediately; potentially restore or redirect to a relevant replacement. |
/blog/old-seo-tip | 3 | Review whether the content has a useful replacement. |
/campaign/2023 | 0 | Check whether it is an intentional expired campaign page. |
Review redirect behavior as a link graph
Redirects are not just a list of HTTP responses. They affect how URLs connect to one another.
When auditing redirects, trace the complete route:
Original URL → First redirect → Second redirect → Final destinationThen ask:
- Does the original URL still have a reason to exist?
- Is the final destination genuinely relevant to the original page?
- Can internal links be updated to point directly to the final destination?
- Are multiple old URLs redirecting to an unrelated homepage?
- Are redirect rules conflicting or creating loops?
A redirect should help users and crawlers reach a suitable replacement, not simply hide a broken URL.
7. Check what search engines can actually render
Modern websites often depend on JavaScript to load content, links, navigation, or page metadata. A page that appears complete in a browser may deliver a very different initial HTML document.
Google can render JavaScript, but rendering introduces additional considerations and can affect how content is discovered and processed.
Checklist: Rendering and JavaScript
Diagnose the initial HTML versus rendered HTML
Example: A JavaScript rendering discrepancy
Initial HTML:
<div id="app"></div>
<script src="/assets/app.js"></script>The main content is not present in the initial document.
Rendered page:
<main>
<h1>Technical SEO Audit Services</h1>
<p>Review your website's technical health...</p>
<a href="/contact">Contact our team</a>
</main>The rendered version contains the page's primary content and a crawlable link.
This example does not mean that every JavaScript website needs server-side rendering. It means that the audit should verify what the search engine can access and render, especially on critical page templates.
8. Audit metadata and page-level search signals
Titles, descriptions, headings, and structured data are not a substitute for accessible content. They help describe and organize a page, and they should be reviewed in the context of the page's actual purpose.
Checklist: Metadata and headings
Evaluate metadata in context
A duplicate title does not automatically mean two pages should be consolidated. For example, two location pages might use a similar title pattern while still representing different locations and distinct user needs. You can also review our guides to duplicate title tags, missing title tags, and duplicate meta descriptions.
Review duplicates alongside:
- The page's intended audience.
- Its primary content and search purpose.
- Its canonical URL.
- Its internal links.
- Whether the pages should remain separate.
9. Verify structured data instead of just counting markup
Structured data can help search engines interpret the information on a page and can make eligible content available for certain search result features. It does not guarantee enhanced appearance in search results.
Checklist: Structured data
Distinguish syntax errors from implementation errors
A validator may report that a piece of markup is syntactically valid. That does not mean the markup accurately describes the page.
For instance, a page should not claim to be a product with a specific price when the visible page does not offer that product at that price. Similarly, an article should not be marked up as a product just because it includes a comparison table.
The audit should establish both technical validity and factual alignment with the visible page.
10. Test page performance and mobile usability on representative templates
Performance audits can generate a long list of recommendations, but not every recommendation will produce a meaningful improvement for every page. The most useful approach is to measure real user experience, identify affected templates, and investigate the underlying causes.
Core Web Vitals are Google's set of metrics for loading performance, responsiveness, and visual stability. The current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google's recommended thresholds for good performance are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, measured at the 75th percentile of page visits.
Core Web Vitals at a glance
Checklist: Performance
Checklist: Mobile usability
11. Review HTTPS, security, and website reliability
Security and reliability are foundational parts of website maintenance. An SEO audit should identify technical conditions that make the website unavailable, insecure, or inconsistent for users and crawlers.
Checklist: Security and reliability
Look for patterns, not just isolated incidents
A single server error during a test does not necessarily establish a persistent problem. Investigate whether the issue repeats, affects a particular URL group, or coincides with a deployment or infrastructure change.
A server problem that occurs across a large group of pages may need a different response from a single page that has an outdated redirect rule.
When a crawl reports a high number of errors, use server logs and repeat tests to help determine whether the results reflect actual website conditions or temporary failures.
12. Investigate duplicate URL patterns and unnecessary crawl paths
Large websites can generate numerous URLs that are not distinct content pages. Filters, sort options, tracking parameters, session identifiers, and alternate URL formats can all contribute to a complex crawl landscape.
The audit should identify which URL patterns are useful, which are duplicates, and which need controls.
Checklist: URL architecture
Example: An ecommerce crawl problem
Imagine a store with 500 products, 20 categories, and multiple filters for size, color, and price.
Without controls, the combination of filters and sorting options may generate thousands of distinct URLs. Many of these URLs may have very similar content.
The audit should classify those URL patterns by their purpose:
| URL type | Potential treatment |
|---|---|
| Main category page | Usually a candidate for indexing if it serves a useful search purpose |
| Useful, distinct filtered category | Review its content and demand before deciding how to handle it |
| Multiple redundant filter combinations | Consider crawl controls and internal navigation changes |
| Sorting variation | Usually not a separate search landing page unless there is a distinct reason |
| Tracking parameter | Avoid generating unnecessary internal links to parameterized variants |
| Product URL with an unnecessary parameter | Use consistent internal linking and canonical signals where appropriate |
Do not block all filtered URLs automatically. Some filtered pages may be useful to customers and may serve distinct search needs. Determine the desired outcome before choosing a technical implementation.
13. Review images, media, and other crawlable resources
Images can be a major part of the user experience, especially for ecommerce, travel, and visual content websites. An audit should check whether important assets load correctly and whether the page communicates useful information even when an image cannot be seen.
Checklist: Image and media health
Not every decorative image requires descriptive alt text. The purpose of alternative text is to communicate relevant image information when it is meaningful, not to add keywords indiscriminately.
For important visual content, verify that the page includes enough surrounding text to explain its purpose.
14. Turn audit findings into a prioritized repair plan
A long list of technical issues is not a repair plan. The next step is to determine which findings are confirmed, what they affect, and what action is appropriate.
Instead of assigning arbitrary scores to every warning, assess each finding across four dimensions:
- Search accessibility: Does the issue prevent search engines from reaching or understanding an important page?
- Business impact: Does it affect a page that supports a significant business goal?
- Scope: Does it affect one URL, an entire template, or a large portion of the site?
- Evidence: Is the problem confirmed, suspected, or based on an incomplete crawl?
Four dimensions for prioritizing findings
Use an evidence-based priority matrix
| Priority | Typical conditions | Example response |
|---|---|---|
| Critical | Confirmed, widespread access or indexing problem affecting important pages | Investigate and resolve immediately |
| High | Confirmed issue affecting an important page or shared template | Assign to the responsible team and schedule promptly |
| Medium | Confirmed issue with limited scope or indirect impact | Add to the planned maintenance backlog |
| Low | Minor, isolated issue with no demonstrated effect on important pages | Document and address when appropriate |
| Monitor | Unconfirmed, temporary, or dependent on more evidence | Retest and gather additional data |
These categories are a workflow aid, not a measure of ranking impact. An individual issue may move between priorities as new evidence becomes available.
Create an issue register
Every confirmed finding should have a record that allows another person to understand and act on it.
| Field | Example |
|---|---|
| Issue | Broken internal links to a priority service page |
| Affected URL | /services/seo-audit |
| Evidence | HTTP 404; 42 inbound internal links |
| Scope | Main navigation and related service pages |
| Business relevance | Priority service landing page |
| Priority | Critical |
| Likely cause | URL changed without updating internal references |
| Proposed action | Confirm intended destination, then restore or redirect and update source links |
| Owner | Development team |
| Status | Awaiting implementation |
| Verification | Recrawl the destination and all affected source pages |
The most important fields are the evidence, scope, proposed action, and verification method. Without them, issues can remain in a spreadsheet for months without a clear path to resolution.
15. Use an audit-to-verification workflow
A technical audit should not end when the initial crawl finishes. The repair process needs to be followed by a verification crawl and a comparison against the original findings.
This creates a repeatable process for identifying regressions and establishing whether the changes had their intended effect.
The audit improvement cycle
The audit improvement cycle
- Baseline crawl Capture the initial state, save the crawl configuration, and export the findings.
- Validate findings Confirm the errors against actual pages, source links, and relevant Search Console data.
- Prioritize and assign Record each confirmed issue, establish its scope, and assign a responsible owner.
- Implement changes Fix the underlying cause, not just the individual URLs appearing in the report.
- Run a verification crawl Reuse the original crawl settings so that the before-and-after results are comparable.
- Compare the findings Check which issues were resolved, which remain, and whether new issues appeared.
- Monitor the outcome Use Search Console, server logs, and subsequent audits to assess longer-term changes.
Measure changes rather than just total errors
A reduction in total warnings does not necessarily mean the site is healthier. For example, a crawler configuration change that excludes 500 pages can make the total issue count fall without fixing anything.
Compare equivalent crawl settings and record:
- The number of URLs discovered.
- The number of URLs successfully crawled.
- The number of confirmed issues by category.
- The number of affected priority pages.
- The number of resolved and unresolved issues.
- The number of newly detected issues.
- The status of any critical or high-priority fixes.
Example: An illustrative before-and-after comparison
The figures below are hypothetical examples, not actual SiteAuditLint results.
| Issue category | Before | After | Difference |
|---|---|---|---|
| Broken internal links | 42 | 8 | −34 |
| Missing title tags | 25 | 5 | −20 |
| Missing meta descriptions | 30 | 12 | −18 |
| Redirect errors | 16 | 4 | −12 |
| Total listed issues | 113 | 29 | −84 |
Illustrative issue reduction
Illustrative audit comparison, not actual SiteAuditLint results.
This comparison demonstrates how a report can show the results of repairs, but it does not establish a corresponding increase in rankings or organic traffic. Those outcomes depend on additional factors and require separate measurement.
16. The complete technical SEO audit checklist
The following condensed checklist brings the full audit process together. It is intended for use during a recurring audit, after a site migration, or when reviewing a major website change.
17. How to run the checklist with a crawler
A crawler makes it easier to inspect large URL inventories, follow internal links, and identify recurring technical patterns. For a useful audit, configure the crawl to reflect the website's actual structure and goals.
A desktop SEO crawler such as SiteAuditLint can be used to crawl pages, inspect technical issues, and compare audit findings over time. The important part is to combine crawl data with evidence from Search Console, server logs, and manual inspection.
Recommended audit sequence
| Stage | What to use | Output |
|---|---|---|
| Discovery | Website crawl, XML sitemap, known URL list | Consolidated URL inventory |
| Diagnosis | Crawl reports, Search Console, manual inspection | Validated issue register |
| Prioritization | URL importance, scope, issue evidence | Ordered repair plan |
| Implementation | CMS, developer tools, server or hosting configuration | Completed changes |
| Verification | Comparable recrawl, live URL tests | Before-and-after comparison |
| Monitoring | Search Console and recurring audits | Ongoing technical health record |
The crawler should not be treated as the sole source of truth. It can detect many technical conditions, but it cannot independently establish every indexing decision, business priority, or reason behind a website's architecture.
For example, a crawler may report a page as non-indexable because it contains a noindex directive. Whether that is an issue depends on whether the page is supposed to appear in search. The audit owner must make that decision using the page's intended role.
18. Turn recurring audits into a record of website improvement
A technical SEO audit is more useful when it becomes part of an ongoing maintenance routine rather than a one-time inspection.
A website's technical condition changes when content is published, templates are modified, plugins are updated, redirects are added, or pages are removed. A fix that works today may be undone by a future deployment.
Set up a recurring schedule based on the website's size, change frequency, and business requirements.
| Audit frequency | Typical use |
|---|---|
| After significant deployments | Check for newly introduced crawl and rendering problems |
| After a migration or redesign | Validate redirects, canonical URLs, sitemap coverage, and internal links |
| Monthly | Review key pages and recurring technical issues |
| Quarterly | Perform a broader review of URL architecture, internal links, and indexing |
| As needed | Investigate sudden errors, unusual indexing changes, or major server problems |
For large or frequently changing sites, monitoring should be more frequent and may need to be automated. For a small, relatively stable website, a broader audit on a less frequent schedule may be appropriate.
Maintain a historical record
For every audit, preserve:
- The date and time of the crawl.
- The website's URL scope and crawler settings.
- The number of discovered and crawled URLs.
- The issue categories and affected URLs.
- The repair decisions and responsible owners.
- The verification results.
- Any changes in the audit methodology.
This creates an evidence trail that helps distinguish genuine improvement from changes in crawl scope or reporting.
Conclusion: A checklist should lead to decisions, not just warnings
A technical SEO audit is not complete when every warning has been reviewed or when the number of reported errors has been reduced. It is complete when the important issues have been investigated, the appropriate fixes have been implemented, and the results have been verified. To learn how SiteAuditLint fits into a repeatable crawl-and-compare workflow, visit the product features page or browse our technical SEO articles.
The most useful checklist is one that connects each finding to a specific page or template, identifies the evidence behind it, considers the intended purpose of the affected URL, and establishes a way to confirm that the fix worked.
By organizing the audit around discovery, access, indexing, internal links, rendering, performance, and verification, website owners can build a more consistent maintenance process. Historical comparisons then make it possible to see which problems are recurring, which repairs have held up, and where additional work is still needed.
For technical SEO, the goal is not simply to have fewer errors in a report. It is to maintain a website whose important pages can be discovered, accessed, understood, and kept reliable as the site changes.
Frequently asked questions
How often should a technical SEO audit be performed?
The frequency depends on the website's size, complexity, and rate of change. A stable small website may benefit from a comprehensive quarterly audit, while a large ecommerce website or frequently updated site may require continuous monitoring and more frequent crawls. Major migrations and deployments should trigger additional checks.
What should be fixed first in a technical SEO audit?
Start with confirmed problems that prevent important pages from being accessed, crawled, or indexed as intended. Then address issues affecting high-value pages or shared templates, followed by lower-impact maintenance findings. The priority should be based on evidence and the website's goals rather than the number of warnings alone.
Can a website pass a technical SEO audit and still have poor rankings?
Yes. A technically accessible and well-structured website is not guaranteed to rank well. Search performance also depends on relevance, content quality, competition, and other factors. A technical audit helps identify obstacles and maintenance problems; it is not a guarantee of search visibility.
Are all 404 errors bad for SEO?
No. A 404 can be the appropriate response for a page that has genuinely been removed and has no relevant replacement. Investigate whether the URL is still linked internally, appears in a sitemap, or represents an important page that should be restored. Redirect only when a genuinely relevant replacement exists.
Do all pages need to be indexed?
No. Some pages, such as login pages, private account pages, internal search results, or redundant URL variations, may not be intended for search. An audit should first establish which pages should be indexed, then check whether technical signals support that intention.
Does an XML sitemap guarantee indexing?
No. A sitemap helps search engines discover URLs, but submission does not guarantee that they will be crawled or indexed. Pages still need to be accessible, technically eligible, and suitable for inclusion in search results.
What is the difference between a technical SEO crawl and a full technical SEO audit?
A crawl collects information about URLs and detects technical patterns such as broken links, redirects, metadata issues, and certain indexing directives. A full audit adds context by validating those findings, comparing them with intended site behavior, reviewing external evidence, prioritizing repairs, and verifying the results.