A technical SEO audit is a structured review of the elements that affect how search engines discover, crawl, understand, and index a website. It helps uncover problems such as broken links, incorrect indexing directives, duplicate page signals, redirect waste, and weaknesses in a site’s internal linking and structure.
The goal is not simply to collect error counts. A useful audit shows which pages are affected, how significant each issue may be, and what to investigate or fix first. Repeating the process also makes it possible to compare findings over time and check whether changes have improved the site.
What does a technical SEO audit check?
A technical audit examines how a website is built and connected, then reviews the signals search engines use to access and interpret its pages. The exact checks depend on the website, the crawler, and the audit settings.
- Crawlability: Can crawlers reach the pages that should be accessible, and how many clicks does it take?
- Indexability: Are important pages allowed to be indexed, and are unwanted pages excluded through meta robots tags or X-Robots-Tag headers?
- HTTP status codes: Do URLs return expected responses, or are there 4xx errors, 5xx errors, and unnecessary 301 redirects?
- Internal links: Can visitors and crawlers follow descriptive links to important pages?
- Page elements: Are title tags, meta descriptions, headings, canonical tags, and Open Graph tags present and consistent?
- Content signals: Are there near-duplicate or thin pages that deserve review?
- XML sitemap alignment: Does the sitemap list only live, indexable URLs, and do those URLs also receive internal links?
- Structured data and crawler access: Is JSON-LD markup valid, and do robots.txt rules allow or block search and AI crawlers as intended?
- Security and performance basics: HTTPS coverage, mixed content, HSTS headers, server response time, and HTML page weight.
What an audit report looks like at a glance
Most crawlers open with a site health score and a severity breakdown. These headline numbers are useful for orientation, but they are summaries of many individual checks. The example report scored the site 89 out of 100 and sorted its findings into four severity levels.
The category scores underneath the headline number are usually more informative, because they show where the weakness sits. In the example, internal linking scored lowest and was also the category that fell most since the previous crawl.
The technical SEO audit process
A repeatable audit follows a clear sequence: define the scope, crawl the site, review the results, prioritize issues, make changes, and run another crawl to check the outcome.
1. Define the audit scope and check crawl coverage
Before starting a crawl, decide which website or section to review, whether subdomains should be included, how far the crawler should follow links, and whether it should also seed URLs from the XML sitemap. If you are checking changes, keep the crawl settings consistent with the previous audit where possible.
Coverage matters when interpreting results. A crawl that stops early, excludes paths, or cannot access some pages may not represent the entire website. Record the crawl date, settings, URL limit, and any limitations so future comparisons are meaningful.
How URL limits distort health scores
The site’s audit history shows why scope has to be recorded. Several earlier runs were capped at 100 URLs. Those limited crawls scored 99 or 100 with zero critical issues. Every full crawl of roughly 600 URLs in the same period scored between 89 and 90 with 32 or more critical issues. The site had not improved during the limited runs; the crawler simply never reached the pages with broken links. A score from a partial crawl describes the sample, not the site.
Compare the crawl against the XML sitemap
Sitemap cross-checks are one of the fastest ways to validate coverage and spot pages that rely on the sitemap alone for discovery.
| Sitemap check | Example result | What it tells you |
|---|---|---|
| Indexable URLs listed in the sitemap | 546 | The sitemap covers most of the 589 indexable pages. |
| Indexable URLs not in the sitemap | 43 | Check whether these should be added or are intentionally left out. |
| Sitemap URLs not returning 200 | 0 | No broken or redirected URLs are being submitted. |
| Sitemap URLs that are non-indexable | 0 | Sitemap and noindex signals do not contradict each other. |
| URLs reached only through the sitemap | 33 | These were not found by following links during the crawl and are candidates for orphan page review. |
2. Review response codes and broken URLs
A technical audit checks whether URLs return expected HTTP status codes. Successful pages commonly return a 2xx status, redirects return a 3xx status, client errors such as 404 Not Found and 410 Gone return a 4xx status, and server errors return a 5xx status. These results help identify unavailable pages, wasted crawl budget, and links that may need attention.
The report also identified 20 URLs containing internal links to broken pages. These are related but different findings: one counts URLs returning client errors, while the other counts pages that link to a broken destination. Together they make up all 36 critical findings in the example.
Group broken links by destination, not by source
Reviewing the evidence column reveals patterns that raw counts hide. In the example, a single deleted article was still linked from six different blog posts. Restoring that one URL or redirecting it to a close replacement would clear six of the twenty affected source pages at once. Other patterns in the same report included:
- Two glossary terms that were linked from a related glossary entry but had never been published, a common result of writing internal links before the target page exists.
- A retired product page URL still referenced from two glossary entries.
- An article slug containing an encoded curly apostrophe. It was the only non-ASCII URL in the crawl, and the link to it returned a 404, which suggests the published slug and the linked slug no longer match.
- One URL returning 410 Gone. A 410 signals intentional, permanent removal, so the fix there is removing the internal links, not restoring the page.
Open the affected URL lists and check whether each destination was intentionally removed, moved, or temporarily unavailable. Repair internal links where possible, and use a redirect only when there is a relevant replacement destination. Read how to run a broken link audit and how to find and fix broken internal links.
Check where redirects actually point
All eight redirecting URLs in the example used a 301 status, which is appropriate for permanent moves. The destinations tell a different story. Three redirected to a closely matching replacement article. The other five sent retired articles to the blog index page. Search engines may treat a redirect to a generic hub as a soft 404, so the old page’s signals may not transfer. In addition, 12 pages still linked to redirecting URLs, and one page linked to three of them. Pointing those links directly at the final destination removes a redirect hop for users and crawlers.
3. Check indexing directives and canonical tags
Indexing checks help confirm whether search engines are allowed to include important pages in their results. A crawler can flag pages with noindex directives set in a meta robots tag or an X-Robots-Tag header, while canonical checks show whether a page identifies a preferred URL.
Review the six non-indexable URLs individually. In the example, all six were blog articles rather than utility pages such as login screens or thank-you pages, which makes them worth a closer look. Some may have been deliberately deindexed because they were outdated or off-topic; others may have inherited the directive from a staging setting or CMS toggle. The sitemap check helps here: none of the six appeared in the sitemap, so the signals were at least consistent with each other.
A self-referencing canonical is not automatically a problem; confirm that it points to the intended version and is consistent with internal links and sitemap entries. The absence of hreflang is expected on a single-language site and only needs attention if localized versions exist.
Related reading: noindex issues and how to fix them, common canonical tag problems, and XML sitemap errors.
4. Inspect titles, meta descriptions, and headings
On-page checks can reveal missing or repeated page elements that may make pages harder to distinguish in search results. Use the report to find affected URLs, then review the actual page content before deciding what to change.
| Report check | Finding in the example audit |
|---|---|
| Missing title tags | 0 |
| Duplicate title tags | 8 (four pairs) |
| Titles longer than 60 characters | 151 (ranging from 61 to 93 characters) |
| Titles shorter than 30 characters | 72 (ranging from 17 to 29 characters) |
| Missing or duplicate meta descriptions | 0 |
| Meta descriptions under 70 characters | 1 (45 characters) |
| Missing H1 headings | 0 |
| Duplicate H1 headings | 81 |
| Multiple H1 tags | 0 |
| Pages with no H2 | 0 |
| Missing lang attribute or Open Graph tags | 0 |
These findings call for different checks. Length flags are review prompts, not proof that a title is wrong, because search engines truncate titles by pixel width rather than a fixed character count. Duplicate H1s should be assessed in context, especially on pages generated from shared templates.
For specific troubleshooting, see duplicate title tags, missing title tags, missing meta descriptions, and duplicate H1 tags.
5. Examine internal links and site structure
Internal links help people and crawlers move between pages and distribute link equity. An audit can measure click depth from the homepage, identify links that lead to broken or redirecting destinations, and flag anchor text that does not describe the linked page.
Deep pages often come from pagination
All 17 deep URLs in the example were pages 4 through 20 of a single paginated blog category archive. The deepest, page 12, sat 13 clicks from the homepage, while pages closer to either end of the series were shallower. That shape is typical of a pagination chain where the crawler can only step one page at a time from the first and last pages inward. Numbered pagination with jump links, splitting a large category into subcategories, or linking key articles from topic hubs all reduce click depth.
A deeply linked page is not necessarily a problem if it is low priority. However, important articles buried in deep archive pages may be crawled less often. If pages have no internal links pointing to them at all, they may be difficult to discover through normal site navigation. Learn more about orphan pages and how to find them.
One template can create hundreds of anchor text findings
The report checked 1,537 internal anchors and flagged 595 pages with internal links that had no anchor text. The evidence was identical on every page: two links to the homepage with no text and no image alt text, which points to a shared header or footer element such as a logo image without an alt attribute. That single template fix would clear all 595 findings. The non-descriptive anchor check was narrower but showed a similar pattern, with one page containing 43 “Read more” links that all pointed to the same glossary entry.
External links decay faster than internal ones
| External link status | Links |
|---|---|
| Working (OK) | 959 |
| Redirected | 110 |
| Broken | 35 |
| Could not be verified | 972 |
| Total checked | 1,966 |
Nearly half of the external links could not be verified, which usually means the destination blocks automated requests rather than being broken. Treat that group as unknown, not as errors. Among the confirmed failures, three patterns stood out: a help center subdomain that failed to connect was linked from 11 comparison, product, and support pages; four articles linked to API documentation paths that had since moved; and one article contained a malformed link where two URLs had been pasted into a single href. Links to individual marketplace listings and third-party pricing pages also broke, since those URLs change often.
6. Review duplicate and thin content findings
A crawl can flag pages with identical or similar content and pages with very little text. These findings are useful for identifying pages that deserve editorial review, but they do not determine whether a page should be deleted or combined.
Seven of the thirteen near-duplicates were location-specific landing pages built from one template, each one 88% to 92% similar to the other six. Pages like these need location-specific substance, such as local pricing, availability, or examples, to justify separate URLs; otherwise consolidating them into one page with a location selector may be stronger. The remaining cases were paginated archive pages, which are naturally similar and usually need no action, and one article that closely matched a research page.
The absence of pages under the word threshold does not, by itself, establish that every page has sufficient or useful content. See how to identify and fix duplicate content and how to find and improve thin content.
7. Check structured data and crawler access
Structured data describes page content in a machine-readable format. An audit may check whether structured data is present, whether JSON-LD markup can be parsed, and which schema types each page declares. Crawler-access checks confirm whether specified bots are allowed or blocked by robots.txt rules.
Answer readiness: question headings and FAQ markup
Some crawlers now score how well pages suit answer engines and AI overviews by checking for question-style headings followed by direct answers. In the example, 460 pages used question headings and 135 had none. More telling, 140 pages had four or more question headings without FAQPage markup. That gap is only worth closing where the content is a genuine FAQ. Google has limited FAQ rich results to a small set of authoritative government and health websites since 2023, so the markup now matters more for clarity to machines than for a visible search feature.
The AI crawlers checked in the report were GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Google-Extended, CCBot, and Applebot-Extended. Some of these fetch pages for live answers while others collect training data, so decide on each one deliberately rather than allowing or blocking them as a group.
These results describe the checks included in that report. They do not guarantee that a search engine or AI system will use the page, cite it, or display it. For more on answer-focused search experiences, read about answer engine optimization (AEO) and the discussion around llms.txt.
8. Confirm security, performance, and image basics
Many crawlers also run lightweight security and performance checks. These rarely produce critical findings on a well-maintained site, but they catch configuration gaps that affect every page at once.
| Check | Example result |
|---|---|
| Pages served over HTTP instead of HTTPS | 0 |
| Mixed content | 0 |
| HSTS (Strict-Transport-Security) header | Missing at the site level |
| Missing viewport meta tag | 0 |
| Pages slower than 1,000 ms | 0 (average server response 129 ms) |
| HTML documents over 500 KB | 1 (the blog index, at 664 KB) |
| Images missing alt attributes | 1 page (9 of its 33 images) |
A missing HSTS header is fixed once in the server or CDN configuration. An oversized listing page usually comes from inline data, repeated card markup, or embedded scripts, and trimming it helps mobile visitors on slower connections.
How to prioritize audit findings
Not every finding requires the same response. Prioritize issues by considering the importance of the affected pages, the number of URLs involved, the likely effect on crawling or users, and the effort required to investigate or fix the problem. The example report ranked 18 recommended actions by impact, effort, and reach. The first ten are below.
| Example finding | URLs | Severity | Impact / effort | Possible next step |
|---|---|---|---|---|
| Internal links to broken pages | 20 | Critical | High / Low | Group by destination, then repair, replace, or remove links to unavailable pages. |
| Client error responses (4xx) | 16 | Critical | High / Low | Restore the page, 301 redirect it to the closest live match, or remove links to it. |
| Noindex directive | 6 | Warning | High / Low | Confirm whether each affected article is intentionally excluded from indexing. |
| Links to broken external pages | 42 | Warning | Medium / Low | Fix shared targets such as a help center or docs link first, then single links. |
| Duplicate page titles | 8 | Warning | Medium / Low | Separate tool pages and tutorials by search intent. |
| No question-led sections | 135 | Opportunity | Medium / Medium | Add question headings with direct answers where readers genuinely ask them. |
| Pages more than four clicks deep | 17 | Opportunity | Medium / Medium | Shorten the pagination chain or link key articles from hubs. |
| Near-duplicate content | 13 | Opportunity | Medium / Medium | Differentiate or consolidate the templated location pages. |
| Internal links without anchor text | 595 | Opportunity | Low / Low | Add alt text or a text label to the shared homepage link in the template. |
| Titles over 60 characters | 151 | Opportunity | Low / Low | Front-load the main topic; shorten only where truncation hides meaning. |
Notice that URL count and priority do not move together. The 595-URL anchor text finding ranks below the 6-URL noindex finding because it has less impact per page, even though it is a one-line template fix. Low-effort, high-reach fixes like that are worth batching into the same release as the critical work.
Treat priority labels as prompts for review, not as a replacement for context. Before changing a directive, redirect, or page, confirm the intended behavior with the site owner or developer.
Compare audits to measure progress
Historical comparisons can help show whether technical changes have reduced known issues or introduced new ones. To make a fair comparison, use the same site scope and equivalent crawl settings, and check whether both crawls completed successfully.
The example report compared its results with a full crawl run three days earlier.
| Metric | Previous audit | Current audit | Change |
|---|---|---|---|
| URLs crawled | 597 | 620 | +23 |
| Crawl duration | 23 seconds | 4 min 22 s (stopped) | Much longer |
| Site health | 90 | 89 | -1 |
| Critical | 32 | 36 | +4 |
| Warnings | 15 | 57 | +42 |
| Opportunities | 363 | 1,010 | +647 |
| Total issues | 410 | 1,103 | +693 |
| Broken URLs | 14 | 16 | +2 |
At first glance the issue total nearly tripled while the health score barely moved. The issue-level comparison explains why. Four issue types were new, eight increased, six were unchanged, and none were fixed or reduced. Two of the new types, internal links without anchor text (0 to 595) and links to broken external pages (0 to 42), jumped from zero to their full size in one run. When a finding goes from zero to hundreds between two crawls of the same pages, the likely cause is a check that was added or enabled, not a sudden regression on the site. Those two checks alone account for 637 of the 693 additional issues.
The genuine movement was smaller and more useful. Broken internal link sources rose from 18 to 20, made up of 3 new pages and 1 fixed page. Broken URLs rose from 14 to 16 on the same basis. Those URL-level changes are what a follow-up crawl should confirm.
The site’s first audit makes the same point from the other direction. It scored 99 with zero critical issues, but it crawled only 100 URLs. Compared with the latest 620-URL audit, the report shows 13 metrics getting worse and 5 improving, including average response time falling from 523 ms to 129 ms. Most of that “decline” reflects six times more pages being examined.
A comparison should answer practical questions: Did the targeted errors disappear? Did new issues appear? Were the same sections crawled? Did a template or site release affect many URLs at once? Did the audit tool add new checks? Keeping notes about deployments, content changes, and crawler updates helps explain the results.
How often should you run a technical SEO audit?
The right schedule depends on how frequently the website changes and how important its organic search traffic is. A site with frequent releases or many URLs may need regular crawls, while a smaller, stable site may use a less frequent schedule and run additional checks after significant changes.
- Run an audit after a redesign, migration, URL change, or major template update.
- Recheck affected pages after resolving critical crawl or indexing issues.
- Audit after content pruning or article consolidation, since deleted and merged posts are the most common source of new broken internal links.
- Use a recurring schedule to spot new problems before they spread across the site.
- Keep historical reports and notes so changes can be interpreted later.
Common mistakes when interpreting an audit
- Focusing only on the score: A single score can hide the specific URLs and problems that need attention.
- Assuming every warning is an error: Some findings are informational or need context before action.
- Ignoring crawl coverage: A stopped or URL-limited crawl may not include every relevant page and can produce an inflated score.
- Fixing counts without checking pages: Confirm the intended behavior before changing a URL, directive, or link.
- Fixing symptoms one page at a time: When hundreds of URLs share identical evidence, look for the template, component, or deleted page behind them.
- Reading new checks as regressions: A finding that jumps from zero to hundreds between two similar crawls usually reflects a new rule, not a new problem.
- Comparing unlike audits: Differences in scope or settings can make trends misleading.
Frequently asked questions
What is the difference between a technical SEO audit and a content audit?
A technical audit focuses on crawling, indexing, site structure, response codes, and other technical signals. A content audit focuses more on the usefulness, relevance, quality, and performance of the website’s content. The two overlap when a crawl flags thin, near-duplicate, or cannibalizing pages.
Does a technical SEO audit fix issues automatically?
An audit identifies and organizes findings. Many fixes require someone to review affected URLs and make changes in the website, CMS, or server configuration.
Why can an audit show more issues after changes?
The later crawl may have discovered more URLs, used different settings, applied new checks, or detected new problems after a release. Check crawl coverage and compare affected URL lists before deciding what caused the increase.
Is it fine to redirect deleted articles to the blog homepage?
It is better than leaving a broken link, but it is not ideal. Search engines may treat redirects to a generic page as soft 404s. Redirect to the closest matching article when one exists, and if nothing relevant remains, let the URL return 404 or 410 and remove the internal links pointing to it.
Should every page with question headings use FAQPage schema?
No. Add FAQPage markup only where the content is a genuine list of questions and answers. Most sites no longer receive FAQ rich results in Google, so accurate, well-structured answers on the page matter more than the markup itself.
What should be fixed first?
Start by reviewing issues that affect important pages or prevent users and crawlers from reaching intended content. Consider the number of URLs affected, likely impact, and effort involved, then verify each fix with a follow-up crawl.
Turn audit findings into a repeatable process
A useful technical SEO audit is more than a list of warnings. It connects each finding to the pages involved, reveals the templates and deleted pages that cause problems at scale, helps you decide what to investigate first, and gives you a way to check the outcome after changes are made. Keep the crawl scope consistent, document important fixes, and review trends over time instead of relying on a single score.
Continue learning with the technical SEO article collection, explore desktop SEO crawler features and comparisons, or browse the site auditing features to see how a crawl report can support an ongoing review process.