Technical SEO
Technical SEO Audit: 6 Steps and What to Fix First
Audit the pages that matter, clear access and indexing blockers first, then work through template defects, real-user performance, structured meaning, and AI Readiness.
A useful technical SEO audit is less about chasing a perfect score and more about finding issues that stop important pages from being crawled, indexed, or used successfully. Start with access and indexability, then fix the defects affecting the greatest number of commercially important pages.
What to fix first
Fix accidental sitewide noindex, robots blocks, login walls, broken domain redirects, and widespread server errors before metadata or schema cleanup. Next, repair missing priority pages and conflicting canonical signals. Then work through template-level links, redirects, rendering, Core Web Vitals, structured meaning, and AI Readiness.
Prioritize access, important pages, and repeatable defects
Google's technical requirements describe eligibility, not a ranking guarantee. A page must be accessible to Googlebot, return a successful response, and contain indexable content to qualify for indexing. Search Console URL Inspection then shows what Google knows about a specific URL and helps diagnose whether crawl access, indexing, or the selected canonical is wrong.
A robots.txt disallow rule and a noindex directive solve different problems. Robots.txt controls crawling. A noindex directive controls index eligibility and must be available to the crawler to be read. Blocking a URL in robots.txt is therefore not a reliable way to remove it from Google's index.
The unit of prioritization is an important page or template. One broken product-template canonical deserves attention before an isolated warning on an old tag page. Likewise, an intentional exclusion is not an error simply because Search Console lists it as unindexed.
| Priority | Signal | Examples | Why it belongs here |
|---|---|---|---|
| Fix now | Important pages are blocked, unavailable, or excluded | Sitewide noindex, robots blocks, login walls, broken HTTPS redirects, widespread 5xx errors | An inaccessible or non-indexable page cannot earn a normal Google result. |
| Fix next | Important pages are missing or Google selected the wrong canonical | Unlinked pages, conflicting canonicals, duplicate URL variants, missing sitemap entries | Google needs a discoverable URL and consistent signals about which version should appear. |
| Fix this week | Templates create broken links, redirects, or rendering gaps | Internal 404s, redirect chains, soft 404s, main content absent from rendered HTML | A template-level defect can affect many commercially important pages at once. |
| Fix this month | Real users get a slow or unstable experience | Poor field LCP, INP, or CLS on a high-value template | Use field data to prioritize widespread user-facing problems before isolated lab warnings. |
| Improve after access is sound | Pages are indexable but hard to interpret | Weak headings, missing entity facts, incomplete structured data, unclear answers, thin internal linking | These fixes improve understanding and extraction after the page can be reached reliably. |
How to run a technical SEO audit in six steps
Use a representative sample before attempting a full crawl. The sample should include the homepage, the pages closest to revenue, and one or two URLs from every important template. Expand the audit when the sample reveals a repeatable defect.
Build a list of pages that matter
Outcome: A small audit set tied to revenue, acquisition, or customer use
- Include the homepage, product or service pages, pricing, integrations, important category pages, and the strongest educational content.
- Group pages by template so one defect can be measured across every affected URL.
- Record the current Google clicks, impressions, CTR, and average position for each important page before changing it.
- Separate pages intended for search from login, account, filter, staging, and utility URLs that may be excluded deliberately.
Check crawlability and indexability
Outcome: Proof that Google can reach each priority page and that the page is eligible for indexing
- Use Search Console URL Inspection on examples from every important template.
- Confirm the final URL returns a successful response and does not require authentication.
- Inspect robots.txt, meta robots, and X-Robots-Tag rules for accidental blocks or noindex directives.
- Compare the indexed view with the live test. A live test is diagnostic evidence and does not prove that the indexed copy has changed.
Make discovery and canonical signals agree
Outcome: One preferred URL for each useful page and a clean path for crawlers to find it
- Link every priority page from another crawlable page with descriptive anchor text.
- Keep the XML sitemap limited to preferred, indexable URLs that return a successful response.
- Make internal links, redirects, sitemap entries, and rel=canonical point toward the same preferred URL.
- Check HTTP and HTTPS, www and non-www, parameters, trailing slashes, and other duplicate URL variants.
Find broken links, bad redirects, and status-code patterns
Outcome: A repair list that distinguishes missing content from temporary transport failures
- Repair internal links that lead to 404, 410, or server-error responses.
- Use a permanent redirect only when a removed URL has a genuinely relevant replacement.
- Shorten redirect chains and prove redirect loops with the actual response path.
- Identify soft 404s, where a missing-page experience returns HTTP 200.
Measure mobile experience and Core Web Vitals
Outcome: Template-level performance work based on real-user evidence when it is available
- Run representative templates through PageSpeed Insights on mobile and desktop.
- Read field data separately from lab diagnostics. Field data describes real visits; lab data helps reproduce and debug a page.
- Use the current good thresholds at the 75th percentile: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1.
- Prioritize a slow or unstable template used by many important pages before chasing a small score change on one low-value URL.
Audit structured meaning and AI Readiness
Outcome: Pages that expose consistent facts to search engines and answer engines
- Make the title, H1, opening answer, and visible product or organization facts agree.
- Use structured data only when it accurately represents content visible on the page.
- Add self-contained answers to real customer questions instead of generic FAQ filler.
- Check that important content and links exist in the server response when non-JavaScript crawlers need to read them.
- Measure AI mentions, citations, crawler requests, and human referrals as separate outcomes. A crawler fetch is not a citation.
Run the page-level baseline
Get a prioritized Technical Audit for one public URL
Foglift checks SEO, AI Readiness, performance, security, and accessibility in one report. Every plan includes unlimited single-page Technical Audits with prioritized findings, shareable results, and PDF export. Launch starts at $49 per month and adds weekly full-site coverage of up to 100 selected pages plus Technical History.
Run a free Technical AuditA clean SEO baseline can still hide an AI extraction gap
Foglift analyzed 854 Technical Audits across 194 distinct domains using one current scoring contract. The latest eligible result for each domain had a median SEO score of 90/100 and a median AI Readiness Score of 60/100. The 30-point difference shows why an audit should measure conventional search health and the extraction layer separately.
The most frequent AI Readiness issue was a missing FAQ section on 141 of 194 sites (72.7%). Few internal links and missing entity identity markup each appeared on 72 sites (37.1%). No structured data appeared on 45 sites (23.2%). These figures describe a self-selected audit sample. They do not prove that adding an FAQ, internal link, entity field, or JSON-LD block will cause a ranking or citation.
The practical conclusion is narrower: once access and indexing work, inspect whether the page exposes clear answers, consistent entity facts, useful internal links, and structured data that matches the visible content. Then measure the actual Google and AI outcomes after deployment.
90/100
Median SEO score
60/100
Median AI Readiness Score
72.7%
Missing an FAQ section
23.2%
No structured data
Read the full sample, methodology, limits, score distribution, and reproducible data artifact in Foglift's AI Readiness study.
Keep an issue log that makes verification possible
A useful audit produces a decision queue, not a screenshot collection. Record the observed evidence, the affected pages, the expected repair, and the verification method before work starts. This prevents a broad warning from turning into an unbounded redesign.
| Issue-log field | Question it must answer |
|---|---|
| Affected page or template | Which URL or repeatable page pattern has the issue? |
| Observed evidence | What did Search Console, the response, or the audit actually show? |
| Commercial importance | Does this page support discovery, evaluation, conversion, or customer use? |
| Scope | How many important URLs share the same defect? |
| Owner and fix | Who can change the source, and what exact change is proposed? |
| Verification | Which test or report will prove the defect is gone? |
After deployment, inspect the affected URLs again and compare the same page-level outcome window. A passed live test proves the tested version is accessible at that moment. It does not prove Google has reindexed the page, improved its position, or sent a click.
Use each audit tool for the evidence it owns
- Page Indexing: site-level indexing coverage, exclusion reasons, and groups of URLs that need interpretation.
- URL Inspection: indexed and live evidence for a specific URL, including access, indexability, and rendered-page diagnostics.
- Crawl Stats: Googlebot request volume, response codes, file types, host status, and crawl-purpose trends for the property.
- PageSpeed Insights: field experience where available plus lab diagnostics for performance debugging.
- Rich Results Test: syntax and eligibility checks for supported structured-data features. Valid markup does not guarantee a rich result.
- Foglift Technical Audit: one report covering SEO, AI Readiness, performance, security, and accessibility with prioritized page findings.
- A full-site crawler: repeated status, link, canonical, metadata, and architecture patterns across a larger URL inventory.
Primary documentation and evidence
- Google Search technical requirements. Access, successful responses, and indexable content.
- Google Search Console URL Inspection. Indexed and live-test evidence for one page.
- Google Page Indexing report guidance. Site-level indexing coverage and page-level diagnosis.
- Google canonicalization guidance. Canonicals, redirects, and sitemap signals.
- Google Core Web Vitals guidance. Current field metrics and thresholds.
- Google structured-data guidelines. Visible-content agreement and no rich-result guarantee.
- Foglift Research: AI Readiness across 194 websites. 854 audits, one current score contract, and explicit sample limits.
Frequently asked questions
What should I fix first in a technical SEO audit?
Fix sitewide access and indexing blockers first: accidental noindex rules, robots blocks on important pages, login walls, broken HTTPS or domain redirects, and widespread 5xx errors. Then fix important pages that are missing from Google or use the wrong canonical. Template-level broken links, redirect chains, rendering gaps, and poor real-user Core Web Vitals come next.
Can I run a technical SEO audit myself?
Yes. Start with Google Search Console Page Indexing, URL Inspection, Crawl Stats, your robots.txt and sitemap, PageSpeed Insights, and a page-level Technical Audit. Test representative URLs from each important template and keep an issue log with evidence, scope, owner, fix, and verification method.
Does every non-indexed page need to be fixed?
No. Login pages, internal search results, filters, staging URLs, and duplicate variants may be excluded intentionally. Prioritize pages that should attract, educate, convert, or support customers. Search Console exclusions need interpretation, not automatic reversal.
How often should I run a technical SEO audit?
Run one before and after a migration, redesign, CMS change, major template release, or unexplained search decline. For ongoing maintenance, repeat representative page checks after deployments and schedule broader site coverage often enough to catch template-level regressions.
Is a high technical audit score enough to rank or earn AI citations?
No. Technical readiness makes a page accessible and easier to interpret. Rankings and AI citations also depend on relevance, usefulness, authority, freshness, competition, and the sources each engine retrieves. Measure Google clicks and AI citations or referrals separately after a fix ships.
What does Foglift's free Technical Audit check?
Foglift checks one public URL across SEO, AI Readiness, performance, security, and accessibility. Every plan includes unlimited single-page Technical Audits with prioritized findings, shareable results, and PDF export. Launch starts at $49 per month and adds weekly full-site coverage of up to 100 selected pages plus Technical History.
Start with the page you cannot afford to lose
Run a free Technical Audit on one important URL, save the baseline, and fix the highest-severity issue you can verify. Re-scan after deployment, then compare Google clicks and AI referrals or citations on their own timelines.
Audit a public URLFundamentals: Learn about GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization) (the two frameworks for optimizing your content for AI search engines).
Related reading
Run a free Technical Audit
Check SEO, AI Readiness, performance, security, and accessibility for one public URL.
Single-page vs full-site Technical Audits
Choose the audit scope, cadence, and report that fits the job.
AI Readiness across 194 websites
Review the reproducible 854-audit benchmark behind this guide.
JavaScript, React, and Next.js SEO
Diagnose what search and AI crawlers can receive from a JavaScript site.