Skip to content
Search

Technical SEO audit: find issues holding back search

A practical, step-by-step technical SEO audit that finds crawl, render, index, and performance problems and shows how to verify and prioritize fixes.

Technical SEO Audit: Find Issues Holding Back Search

What a technical SEO audit checks

A technical SEO audit is a focused, evidence-driven review of the systems that let search engines discover, render, index, and understand your pages. The goal is to find the technical obstacles that reduce visibility, waste crawl budget, break user experience, or create ranking ambiguity.

Key areas to inspect

• Discovery and crawlability — robots.txt, server responses, sitemap coverage, internal linking, and redirects
• Indexing signals — meta robots, X-Robots-Tag headers, canonical tags, and noindex usage
• Rendering and JavaScript — server-side vs client-side rendering, resource blocking, and how pages look when rendered
• Site performance and page experience — Core Web Vitals field data, server response times, and resource loading
• Duplicate content and URL canonicalization — parameter handling, trailing slash variants, and pagination
• Structured data and SERP features — markup accuracy and eligibility for rich results
• Internationalization and hreflang correctness
• Security and accessibility — HTTPS coverage, mixed content, and secure headers

How to run a technical SEO audit (step-by-step)

1. Define scope and success metrics

Start by deciding which parts of the site you will audit and why. Examples: an entire domain, a subdirectory, a large product category, or a set of landing pages. Decide measurable success signals (indexation of canonical pages, reduced server errors, improved Core Web Vitals percentiles, visibility of specific URL groups).

2. Create an inventory

Gather a representative URL list from sitemaps, analytics, server logs, internal links, and known landing pages. This inventory is your audit surface — keep it in a spreadsheet or a crawler project so you can tag and filter URLs as you work.

3. Crawl and compare (external crawl + server logs)

Run an external crawl to emulate a search engine’s discovery of pages. Combine crawl results with server logs to see which URLs search engines actually request. Server logs reveal how often crawlers fetch pages and whether redirects, soft-404s or frequent errors appear in production.

To inspect headers only: use curl -I https://example.com/page to see status and header fields. To fetch the HTML that a particular user-agent would receive: use curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page and save the output for comparison.

4. Verify indexability and canonical intent

For pages you own, use Google Search Console URL Inspection to check how Google indexed a URL and whether any indexing issues were detected. For third-party pages (publishers, partner sites), use external checks: view-source, curl, rendered DOM checks in Chrome DevTools, and public index signals such as the site: operator as an indication (not proof) that Google knows about a URL.

5. Test rendering and JavaScript behavior

Open pages in Chrome DevTools, use the Elements and Network panels to confirm resources load and are not blocked, and check the rendered DOM for content injected by JavaScript. If a piece of critical content appears only after user interaction or late in the render lifecycle, note the risk to visibility and the testing steps to reproduce it.

Use the Rich Results Test and the Schema Markup Validator (schema.org) to validate structured data and detect errors that would prevent eligibility for rich results.

6. Measure page experience and performance

Collect field metrics (Core Web Vitals) from Search Console and lab profiles from Lighthouse or local testing. Field data reflects real users; lab data helps reproduce problems locally. Prioritize fixes that affect real-user metrics for pages that matter to search visibility.

Verification and troubleshooting

Troubleshooting is a detective process: reproduce the symptom, isolate variables, and test fixes. Use a combination of public and owner-only tools.

Useful verification steps

• Check server responses: curl -I will show HTTP status, content-type and X-Robots-Tag headers.
• Inspect the delivered HTML: curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com/page and compare with a browser fetch to detect content differences.
• Rendered DOM check: open the URL in Chrome, disable cache, and use Elements to confirm that important content is present in the DOM without requiring user interaction.
• Indexing proof (owned pages): Google Search Console URL Inspection shows index status and reasons for exclusion.
• Structured data: run the Rich Results Test and Schema Markup Validator to see parsing and errors.
• Field performance: review Core Web Vitals in Search Console for real-user metrics; use Lighthouse or lab runs to reproduce the slow cases.
• Crawl activity: compare crawler requests in server logs to your sitemap and known pages to identify gaps or excessive crawling on low-value URLs.

Common mistakes and misconceptions

• Treating tool warnings as the audit: Crawlers surface many signals; the audit’s job is to interpret which warnings matter for your business goals.
• Confusing crawling with indexing: being fetched by a crawler does not guarantee a page is indexed or will rank.
• Relying on site: as definitive proof: site: is a useful public signal but not authoritative. For owned pages, use URL Inspection in Search Console.
• Blocking critical assets: robots.txt or server rules that prevent CSS/JS can change how Google renders pages and may break Core Web Vitals or structured data detection.
• Incorrect canonical or redirect chains: canonical tags that point to non-canonical content or long redirect chains create ambiguity and slow crawls.
• Assuming rel="nofollow" means zero value: Google treats rel="nofollow" as a hint; its handling is not a simple on/off switch.
• Ignoring indexability of publisher or partner pages: a backlink or mention is less useful if the page is not indexable or is hidden behind authentication.

When paid placements or sponsored content are involved, follow Google’s guidance: mark paid/compensated links with rel="sponsored" or rel="nofollow" and use rel="ugc" for user-generated links. Remember: there is no rel="dofollow" attribute; a standard link is simply one without rel=nofollow/sponsored/ugc. Google’s linkspam guidance indicates that links intended primarily to manipulate rankings can be treated as link spam, so ensure editorial context, indexability, and transparency when working with external placements.

Checklist: high-impact items and how to verify them

Use this compact checklist to verify the most common high-impact technical issues. For each item, the right verification tool is noted.

1) Canonical intent: Are canonical tags consistent and pointing to the desired URL? (Verify: view-source, compare with HTTP headers, and use an external crawler.)

2) HTTP status and redirect chains: Do important pages return 200 and non-redirect errors, and are redirects minimal? (Verify: curl -I and server logs.)

3) Robots and meta robots: Are important assets or pages unintentionally blocked? (Verify: robots.txt fetch, X-Robots-Tag in headers via curl -I, and meta robots in HTML.)

4) Indexing anomalies: Are pages excluded for technical reasons (noindex, canonical pointing elsewhere, soft-404)? (Verify: Google Search Console URL Inspection for owned pages; for external pages, compare HTML + public index signals.)

5) Rendered content parity: Does the HTML that search engines see include the same critical content as users see? (Verify: curl with appropriate UA, Chrome DevTools rendered DOM.)

6) Structured data correctness: Is structured data valid and up to date? (Verify: Rich Results Test and Schema Markup Validator.)

7) Core Web Vitals and load performance: Do field metrics show problems for your key pages? (Verify: Search Console Core Web Vitals report and lab testing with Lighthouse.)

Prioritization: choose fixes that move the needle

Prioritize work by combining three dimensions: relevance to business goals (which pages matter for search traffic or conversions), technical severity (blocking indexation, causing frequent errors), and effort to fix. Quick wins often include fixing misconfigured noindex tags, eliminating redirect chains for high-traffic pages, and unblocking critical CSS/JS that affects rendering.

Reporting and monitoring

Deliver an audit report that groups issues by priority, shows examples and repro steps, and includes a recommended rollout plan. Add monitoring for regressions: track server errors, indexation changes via Search Console, and Core Web Vitals field metrics. After fixes deploy, re-run the exact verification steps used during the audit to confirm resolution.

FAQ

How is crawling different from indexing and ranking?

Crawling is the process of discovering and fetching URLs. Indexing is the decision to store some or all of a page’s content in the search index. Ranking is the ordering of results when a query is issued. A page can be crawled but not indexed, and being indexed does not guarantee a high ranking; each stage has separate signals and checks.

What if I see different HTML when I fetch a page as Googlebot?

First, confirm whether the difference is intentional (device-optimized content) or accidental (server misconfiguration or user-agent sniffing). Use curl with a Googlebot-like UA to save the HTML, compare it to a normal browser fetch, and check server-side logic that varies output by UA or headers. Avoid serving substantially different content to crawlers versus users.

How do I check whether a publisher page with a backlink is indexable?

From the outside, check the page’s HTML for meta robots, use curl -I to inspect X-Robots-Tag headers, and confirm the page returns a 200 status. Use the rendered DOM in a browser to ensure the link is present in the static or rendered HTML. The site: operator can indicate public index signals but is not definitive.

Does fixing technical issues guarantee ranking improvements?

No single technical fix guarantees ranking gains. Technical work removes obstacles and improves the likelihood that strong, relevant content can compete. After fixes, monitor indexation and performance signals and combine technical improvements with content and relevance work.

Since Google uses mobile-first indexing, what should I check first?

Google uses the mobile version as its primary basis for crawling and indexing. Since July 2024, Google crawls sites for Search with Googlebot Smartphone by default. Verify that the mobile HTML exposes the same critical content, metadata and structured data as the desktop version, and ensure mobile performance and responsive behavior are acceptable.

Related articles