Currently Available: Need a skilled Software Developer for your next project?

SEO, GEO and AEO

Technical SEO Audits and Fixes

November 11, 2026 by Vincent Schmalbach

A technical SEO audit checks whether search engines can discover, fetch, render, index, and show a site’s intended pages in search results. Each finding should identify the affected URLs, evidence, likely technical cause, proposed fix, and post-release check. A tool warning is a lead, not a diagnosis.

An audit establishes technical conditions, but it does not prove that a fix will improve rankings, traffic, citations, or sales. Google uses many signals and systems to rank results, so fixing an access or indexing problem does not guarantee visibility for a query. Content usefulness, query targeting, and external links require separate work.

A limited, dated example shows the difference between an observation and a conclusion. On November 11, 2026, an HTTP request without crawler-specific authentication returned HTTP 200. The inspected page had a self-referencing canonical tag, which identifies the page as the preferred version of that URL, and no robots meta noindex directive. Those findings apply to one URL at one point in time. They do not confirm that a search crawler visited the page, that the page entered a search index, or that it gained search visibility.

Trace the search pipeline

Google Search handles discovery, fetching, rendering, indexing, and serving as separate stages. A successful browser request confirms that the browser received a response; separate evidence is needed to determine whether Google discovered, fetched, indexed, or served the URL. Google’s overview of how Search works describes this sequence; other search engines use their own processes.

Discovery and fetching

Discovery means Google learns that a URL exists through links, sitemaps, or other sources. Fetching means a Google crawler requests the URL. An XML sitemap entry does not show that Google discovered or fetched a URL, and an ordinary GET request does not show the response Google received.

When a URL appears undiscovered or unfetched, compare internal links and sitemap entries with crawl logs and Search Console data. Check the robots.txt rules for the relevant crawler, along with DNS, TLS, CDN or firewall behavior, server capacity, and the actual response.

A user-agent string does not verify Googlebot traffic. Verify the user agent, source IP address, and reverse DNS. Then perform a forward DNS lookup to confirm that the hostname resolves back to the same IP address. Google’s crawlers use multiple IP ranges. Google also distinguishes common crawlers, special-case crawlers, and user-triggered fetchers, which do not all follow the same robots rules. See Google’s crawler documentation.

Rendering and indexing

Google may process a fetched page’s HTML, JavaScript, and required resources to render it. Blocked or failing scripts, APIs, stylesheets, and other resources can leave important content or links out of the rendered page. Compare the response HTML with rendered-page evidence for the elements that matter.

Google makes a separate decision about indexing. Google can fetch and render a page yet exclude it, treat it as a duplicate, or select another canonical URL. Use URL Inspection, response HTML, rendered-page evidence, and index reports together. A live test shows the current response; it does not confirm that Google indexed the URL.

Serving a search result

For each query, Google selects indexed material and decides what to display. Indexing makes a URL eligible for consideration, but does not secure a ranking or appearance for a particular query.

For Google AI features, pages must be indexed and eligible to appear in Search with a snippet before Google can consider them. That requirement does not guarantee selection or citation in an AI feature.

Why reports disagree

A live test examines the page as it responds now, while an indexing report reflects Google’s earlier processing of the URL. A page can pass the live test and remain excluded from the index. Check the timestamp and status before treating the difference as a fault. Google’s URL Inspection documentation distinguishes live-test results from indexed-URL information.

Build a reliable audit record

A finding is useful when another operator can repeat the check on the same URLs, inspect the evidence, and confirm whether the fix worked. Record the check date and its source or tool. Then note the method, scope, and result. List the exact affected URLs and saved evidence. Then record the likely cause and proposed fix, along with the owner, priority, and verification method. Treat the cause as a hypothesis until the evidence establishes it.

Attach raw URL lists, crawler exports, and test output to each finding so another operator can reproduce totals, inspect individual URLs, and determine whether the fix covered the reported scope. For Google Search Console findings, record the property, report, and inspection method. Google’s URL Inspection tool separates indexed information from live-test results.

Inventory versus sample

A site-level inventory is a documented attempt to list a defined URL population, such as URLs submitted in a sitemap or found by a crawler. A sample is a selected subset examined in depth. Label each clearly because they support different conclusions.

No single source represents every URL known to a search engine. A crawler finds URLs reachable from its starting points and links. Server logs show requests received by the server. Sitemaps, analytics landing-page reports, and Search Console exports each describe a different URL population. Compare them and state what each source excludes.

Normalize and deduplicate URLs before comparing totals, while preserving meaningful variants until the audit confirms that they resolve to one URL. Language versions, pagination, parameters, hostnames, and protocols may indicate separate pages or separate technical conditions.

For sampled tests, record the selection rule, sample size, and tested URLs. Include relevant templates, such as product pages and filtered listings. Add localized and paginated pages as edge cases, along with known errors. A passing sample supports a conclusion about the URLs tested; it does not establish that untested templates behave the same way.

Reproduce each finding

Turn every tool warning into a repeatable URL-level check. Record the requested URL, redirect chain, and final URL. Add the HTTP status and relevant headers. Note the robots directives and canonical target. Include rendered content when rendering affects the result. Record the browser or crawler configuration and request method. Include any other test conditions.

A normal GET request shows the response that client received, but does not prove that a search crawler received the same response. For suspected Googlebot traffic, use Google’s crawler-verification method: verify the source IP through reverse DNS, then confirm that the hostname resolves back to the same IP. Do not rely on the user-agent string alone.

For high-risk changes, preserve the original response and test output before release. Retest the same URLs under the same conditions afterward, then report the results for each URL as passed, failed, or not tested. Before work begins, assign an owner, set priority based on severity and affected pages, and define the verification check. A fix is verified only for the URLs and conditions retested.

Check site structure and access

Map the URLs a crawler reaches through internal links, then compare that map with sitemap URLs and server logs. Each inventory answers a different question: an XML sitemap lists URLs the site owner wants search engines to discover, while server logs record requests that reached the server. Important URLs that appear in only one inventory need investigation.

Important pages need descriptive HTML links from relevant navigation, category pages, listings, or related content. Check that listing and pagination pages expose later items through stable URLs. Crawl depth - the number of links between a starting page and a URL - can reveal weak routes, but no universal depth limit blocks indexing. For a detailed method, see how to find important pages with no useful internal links.

Inspect robots rules

Fetch the live /robots.txt file and test each affected URL against the relevant crawler’s user-agent group. Check for broad Disallow rules and staging rules left in production. Then review overlapping groups. Also check whether Google needs any blocked resources to render the page. Google documents the format and its handling of rules in its robots.txt documentation.

For crawlers that follow it, robots.txt controls access to URL paths, but it does not reliably keep a URL Google already knows out of search results. If a page needs a noindex directive, allow Google to fetch the page and read it; a robots.txt block prevents Google from checking the directive.

Inspect sitemap output

Request the sitemap URL. Check its HTTP response, XML structure, and listed URLs. Listed URLs should use the preferred host and protocol and resolve to the intended indexable page, rather than a redirect, error page, noindex page, or non-canonical duplicate. A URL path containing index does not prove that the response is a sitemap index; check whether the XML root element is sitemapindex or urlset.

Check sitemap references in robots.txt and the submission status in Search Console. Submission does not guarantee crawling or indexing. For deeper diagnosis, see why a sitemap URL may still be missing from search and how to audit Yoast sitemap output.

Trace internal URL paths

Compare crawler-discovered URLs with sitemap entries and log requests. When an important URL appears in a sitemap or logs but not in the link crawl, inspect its inbound links and the route intended to expose it. Also find internal links that lead to redirects, errors, or unintended URL variants.

For filtered listings, separate useful parameter combinations from duplicate or low-value URLs. Then check how internal links, canonical tags, and crawl rules handle each pattern. If a listing uses infinite scroll, later items also need stable paginated URLs and crawlable links. A user’s scroll action does not provide a reliable discovery path.

Read crawl depth in context

A page can sit far from the home page and still have a clear route through relevant category and pagination pages. Prioritize important pages with no useful inbound links and links that lead to broken or unintended destinations. After changes, recrawl the affected sections and confirm that intended URLs are reachable and return the expected response.

Does a deep URL need to move closer to the home page? Change links when the current route makes discovery or navigation unreliable, rather than to meet an arbitrary depth threshold.

Verify responses and URL signals

Assess each affected URL as a set of connected signals. Record the requested URL, every redirect hop, final URL, final status code, canonical target, robots directives, indexability, sitemap presence, and test date.

Requested URL	Redirect chain	Final URL	Status	Canonical	Robots directives	Indexability	In sitemap?
Exact URL tested	Every hop, or none	Exact destination	Final response code	Exact target	Meta robots and `X-Robots-Tag`	Eligible, blocked, or excluded; state why	Yes or no

Inspect response headers and HTML in a browser and with the relevant crawler user agent. A CDN, firewall, authentication layer, or user-agent rule can return different content or status codes. Google states that inappropriate response codes can affect how pages appear in its products; use its crawler documentation for Google-specific behavior.

Classify HTTP responses

The status code should match the URL’s actual state. Investigate important URLs returning 4xx or 5xx, missing pages that return 200 OK, redirect loops, long chains, and inconsistent HTTP, HTTPS, or hostname variants.

A soft 404 returns a success status while the page appears missing. Check both the HTTP response and the rendered page. Return 404 Not Found or 410 Gone when removed content has no relevant replacement. Redirect a removed URL only to a close replacement; redirecting unrelated missing URLs to the homepage conceals the real outcome.

Where conditional caching matters, inspect ETag and Last-Modified headers. Investigate malformed or contradictory validators. Those headers do not establish when Google will recrawl the URL.

Check redirect destinations

A redirect tells a client to request another URL. Test each hop, then confirm the final destination returns the intended page. Use a permanent redirect for a permanent move and a temporary redirect for a temporary move.

Where appropriate, point internal links, canonical links, hreflang references, and sitemap entries directly to the preferred destination. For crawler-specific testing, see how to test redirect handling.

Compare canonical signals

A canonical link identifies the preferred URL among duplicates or similar URLs. Search engines treat it as a signal and can still select another URL.

Compare the declared canonical with redirects, internal links, sitemap entries, page content, and URL variants. Flag canonical targets that redirect, fail, are blocked, are unrelated, or point across domains by mistake. Inspect both response HTML and rendered HTML when templates generate canonicals. Keep translated or regional pages separate when they serve different audiences. See Google’s canonicalization guidance and this canonical error diagnosis.

Check noindex directives

Check both the HTML robots meta tag and the X-Robots-Tag response header. Either can contain noindex. Record the exact directive, then inspect template defaults, staging settings, and environment-specific deployment rules.

Confirm that the crawler can fetch the URL and read the directive. A robots.txt rule controls crawling; noindex requests exclusion from search results. Use Google’s robots meta tag documentation to compare the live response with the state reported in URL Inspection.

A sitemap entry or 200 OK response does not prove that a page is indexable or indexed.

Common misread: Check for a soft 404 when a page returns 200 OK but displays a “not found” message.

FAQ: Does blocking a URL in robots.txt remove it from search? No. A crawl block does not provide a noindex directive, and a blocked URL can still appear in search results.

Test JavaScript and mobile pages

Test representative URLs from each important template, along with known problem URLs. Compare the initial HTML response, rendered DOM, and content visible to visitors. Record the URL, template, viewport, date, test conditions, and the content container or elements checked. A passing result applies only to the pages tested; when the same defect appears across a template, expand the review to that template’s URL inventory.

Inspect rendered content

JavaScript can fetch resources and alter a page after the server returns its initial HTML. Inspect the document response in the browser’s Network panel or with a direct HTTP request. Then compare it with the DOM (the page structure after scripts run) and the visible page.

Confirm that the page title, main text, important links, product details, canonical annotation, and structured data appear as intended after rendering. Important content should load without a click, hover, scroll action, or other user interaction. Content present in the DOM but hidden behind an overlay or collapsed control also needs investigation.

Use Chrome DevTools to find failed JavaScript files, blocked API requests, and hydration errors. Hydration is when client-side JavaScript attaches behavior to HTML already returned by the server. Check consent overlays and other elements that cover or prevent access to content.

For Google-specific checks, use Search Console’s URL Inspection tool to test a live URL and review Google’s rendered-page information. Google’s JavaScript SEO guidance covers its current rendering guidance.

For lazy-loaded images, verify that the image URL is available in crawlable HTML and that loading does not require user interaction. For a focused check of response HTML without JavaScript, see how to check whether important content exists without JavaScript.

Check mobile behavior

Google indexes the mobile version of a page as its primary version. Mobile-first indexing does not create a separate mobile ranking system, so content or indexing signals omitted from mobile pages may be unavailable to Google.

Compare mobile and desktop pages for unintended differences in main content, links, or images. Check metadata, canonical annotations, and robots directives too, along with structured data. Google’s mobile-first indexing documentation calls for equivalent primary content and indexing signals.

Test responsive layouts at practical mobile viewport sizes. Confirm that text is readable, controls work, and important content is not clipped, hidden, or covered by overlays. Use Search Console and current browser tools; the retired Mobile-Friendly Test is not a current verification method.

Measure page experience correctly

Core Web Vitals measure a web page’s loading, interaction responsiveness, and visual stability. Google defines them as Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

A page meets the “good” threshold when the 75th percentile of real-user visits meets all three targets. Those targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Review mobile and desktop separately, as Google’s Core Web Vitals documentation specifies.

Core Web Vitals are page-experience signals. They do not guarantee higher rankings; relevance and other Google Search systems still matter. Use the metrics to find and fix user-experience problems rather than to predict search visibility.

Separate field and lab data

Field data measures real visits under varied browsing conditions, including differences in devices, networks, and locations. Search Console and PageSpeed Insights report this Chrome user data when enough data exists for a URL or URL group. Search Console groups similar URLs, and low-traffic pages or groups may lack a field report. Check the device category and URL group before drawing conclusions, as described in Google’s Search Console documentation.

Lab data comes from testing one URL in a controlled setting. Use Lighthouse or browser developer tools to reproduce a problem and investigate it. Record the URL, device emulation, network settings, cache state, location, and test date. Repeat tests under the same conditions.

A lab run measures one page under one test environment. It does not represent site-wide performance or replace field data. A passing lab sample also does not show that every URL in a field-data group meets the thresholds.

Trace the performance cause

Start with the failed metric, not a single performance score. For LCP, identify the largest visible element and inspect resource discovery, request timing, image dimensions, server response, and render-blocking CSS or scripts.

For INP, test interactions that matter to users. Inspect long main-thread tasks and event handlers, and check for delayed screen updates. For CLS, look for images or embeds without reserved space and banners inserted above content. Check for font swaps and other content that moves visible elements. Google provides diagnostics for LCP, INP, and CLS.

Use the network waterfall and performance trace to distinguish server delay from resource transfer, script execution, rendering, and interaction work.

Record and verify findings

For each finding, save the URL, metric, device category, and data type. Add the date and test conditions. Attach the field report or lab trace, identify the measured cause, and prioritize affected URL groups.

After a change, repeat the same lab test. When real-user data is available, assess field trends separately. A higher Lighthouse score alone does not prove that visitors experienced an improvement.

Does a passing lab test mean a URL passes Core Web Vitals? No. It records one URL under chosen conditions. Field data reflects real visits and determines the reported Core Web Vitals assessment.

What if Search Console has no field data? Use lab tests to investigate the URL, and state clearly that field data is unavailable. Do not describe a lab result as a field-data pass.

Validate structured data

Structured data uses machine-readable code, often JSON-LD, to describe the entities and facts on a page. It supports eligibility for specific search features when the markup meets a search provider’s requirements. Valid markup does not guarantee that Google will show a rich result or select the page for an AI-generated response.

Match every marked-up fact to content visitors can see on the page. Choose the entity type and properties that describe the page, then focus on features Google currently supports. Google’s structured data policies and supported search features set the relevant requirements.

Fix markup defects

Use the Schema Markup Validator to check JSON-LD syntax and Schema.org vocabulary. Use Google’s Rich Results Test to check whether a URL is eligible for rich result types Google supports. Passing either test does not guarantee that Google will display the feature.

For each issue, record the tested URL and markup type, then save the tool output. Note any missing required properties or warnings, and include the visible page content that confirms the markup is accurate. Correct defects in the page template when they affect multiple URLs. Then retest representative URLs and review the full set of affected pages. Do not add properties the page does not support or mark up hidden content merely to remove a warning.

When JavaScript generates JSON-LD, inspect both the rendered page and the initial HTML response. After deployment, confirm that the expected entities appear once and that no other markup omits, duplicates, or contradicts them.

Set realistic search expectations

Google chooses whether an eligible rich result appears in search and how it looks. Google’s guidance for AI features in Search does not require special AI markup. Structured data does not guarantee that Google will select, link to, or cite a page in an AI feature.

Useful FAQ content answers real reader questions. FAQ markup does not make content eligible for search features Google does not support for that content type. FAQ content and structured data solve different problems: the content answers the reader’s question, while the markup describes that content for search engines.

Plan safe site migrations

A domain, protocol, URL-structure, or platform migration changes how visitors and search engines reach content. Treat it as one coordinated release: document the current site, map each old URL to its intended destination, and test the live site after launch.

Before release, collect old URLs from XML sitemaps and internal-link crawls. Check analytics landing-page reports, Search Console, and server logs as well. Each source reveals different URLs, so note its limits and retain valuable URLs even if they appear in only one source. Save crawl results and indexing data as a baseline. Record traffic and error data there too. Prioritize URLs with meaningful traffic, external links, conversions, or business value.

Create a direct old-to-new URL map before configuring redirects. Send each moved URL to its closest relevant replacement. When no relevant replacement exists, return an appropriate not-found response instead of redirecting visitors to the homepage or a generic category page. Avoid redirect chains, loops, and redirects that send many unrelated pages to one destination. Google recommends testing redirects and keeping them for at least one year.

Prepare redirects with canonical tags, internal links, hreflang references, sitemap output, robots rules, DNS records, and CDN settings. Preserve useful page content and important external references where possible. See what to preserve during a migration when other sites or AI answers cite the pages.

Check before launch

Crawl the staging site while access controls are active. Confirm that production will not inherit staging noindex directives, blocked paths, test canonical URLs, or temporary hostnames.

Test a representative set of old URLs against the redirect map, checking each HTTP status and final destination. Review the destination content too. Compare the old and new page inventories for missing pages or changes to templates and metadata, and check whether internal links still point to retired URLs. A representative sample exposes repeated configuration errors; validate every redirect rule when the migration scope makes that practical.

Verify after launch

Crawl the old and new URL lists in production. For each old URL, check its response and redirect path. Then verify the final destination and its content. Confirm that important new pages are indexable, declare the intended canonical URL, and receive internal links.

Update and submit the new sitemap. Monitor Search Console indexing, crawling, and performance reports while Google processes the move. Compare server logs and analytics with the pre-launch baseline. Investigate unexpected 404 responses, 5xx server errors, incorrect redirect destinations, and changes in crawler access before linking traffic movement to the migration.

For a domain or subdomain move, use Google’s Change of Address tool after the new site is live and redirects work. The tool creates no redirects and does not cover protocol-only or path-only changes. Keep an exception list for old URLs intentionally retired or without a relevant replacement.

Prioritize and verify fixes

Turn each confirmed defect into a fix that someone can assign and retest. Record the affected URLs or template, evidence, and test date. Add the likely cause and proposed change, then name the owner, dependencies, and implementation risk. Finish with a success check. Keep the exact URL list with the finding. A warning without confirmed affected URLs is not yet a scoped fix.

Rank work by evidence

First fix confirmed access or indexing blockers on important pages. Give similar priority to incorrect redirects, migration errors, and broken URL patterns that affect many pages. A template defect can affect thousands of URLs, so record the tested scope and affected count instead of treating it as an isolated warning.

Next, address repeatable template defects where pages remain accessible but the search consequence remains uncertain. Keep isolated warnings and unconfirmed performance opportunities at lower priority until you identify affected URLs and reproduce the problem. Raise priority when a defect is time-sensitive, user-facing, security-related, or tied to a migration, and record why.

Separate measured impact from estimated impact. A crawl export counts the tested URLs that share a defect; it does not prove lost rankings or traffic. Third-party authority and difficulty scores do not establish a Google issue or justify deleting pages or disavowing links.

For example, a canonical finding should identify the preferred URL and suspected duplicates, then compare redirects, canonical tags, and sitemap entries. Confirm that the pages are genuine duplicates before consolidating them. Google treats canonical annotations as signals and can select a different canonical, as its canonicalization documentation states.

Key takeaway: Prioritize confirmed defects by affected scope, page value, urgency, and implementation risk, not by a vendor score or assumed traffic loss.

Verify the correction

After release, rerun the original test on the same URLs and compare the number that still fail. Inspect representative URLs from every affected template. Record passed, failed, untested, and exception URLs.

For access defects, request the page and required resources, then check status codes, response headers, and crawler rules. For indexing signals, recheck canonical and noindex directives. Check X-Robots-Tag headers where relevant. Use Search Console’s URL Inspection tool to inspect the live page and Google’s reported indexing state. A live test shows the current fetch; it does not confirm that Google has updated its index.

For rendering defects, compare the response HTML with the rendered page for the same content and links. For performance fixes, repeat lab tests under equivalent conditions. Compare field data only when the URL group and measurement period match; web.dev distinguishes field data from controlled lab tests.

Turn findings into tickets

Each ticket should identify the affected URLs or template and attach evidence. It should state any remaining uncertainty and define the retest. For a redirect ticket, list each old URL with its final destination. Include the faulty routing rule and any deployment dependencies.

Do not close a ticket when code ships. Close it when the retest records the result and remaining exceptions. Later search-report changes can support investigation, but timing alone does not prove that a release caused them.

FAQ: What if the original test cannot be repeated exactly? Use the closest direct test, record what changed, and do not compare the results as though conditions were identical.

Read a dated site example

On November 11, 2026, between 13:27 and 13:30 UTC, ordinary public GET requests used the declared user-agent ArticleLab-PublicAudit/1.0. The requests did not impersonate a search provider crawler. They establish only what the named URLs returned during that window. They do not establish whether a search engine fetched, indexed, selected, cited, or recommended those pages.

Report exact observed URLs

Both the Resources page and the Yoast sitemap audit page returned HTTP 200 and included a self-referencing canonical link. Neither inspected robots meta tag contained a noindex directive.

The response from sitemap_index.xml returned HTTP 200 and XML with a urlset root element and 827 immediate url elements. The XML structure identifies what the server returned; the filename does not. At the time of the check, robots.txt advertised /sitemap.xml and /de/sitemap.xml. Each is a separate URL that requires its own inspection.

The normalized text parsed from the HTML response also contained 15 selected browser-visible paragraphs longer than 60 characters from the Yoast sitemap audit page, excluding the comment form. The parser used DOMParser, which does not execute scripts. The selected content container also included an inline promotion, so the comparison does not measure the article’s word count.

Explain what remains unknown

A local robots parser allowed the Resources URL under the declared rules for the tested user agents. That result establishes only how that parser interpreted those rules. It does not establish provider access, crawler identity, or actual crawl activity.

Likewise, one sitemap response does not establish that every sitemap file or listed URL is correct. A match between selected visible paragraphs and one page’s HTML response does not establish that other site templates expose content in the same way.

These point-in-time checks provide no evidence of ranking, traffic, citations, recommendations, or revenue impact.

When a technical fix is not enough

A page can load, render, and remain eligible for Google indexing yet receive little search traffic. Technical checks establish whether Google can access the page and interpret signals such as its canonical URL and indexing directives. They do not establish that the page satisfies the searcher’s need, provides enough useful information, or compares favorably with other results. Google’s ranking systems documentation describes how its systems use relevance and other signals when selecting results.

When the technical evidence shows that the page is accessible, indexable, and correctly canonicalized, stop changing robots directives, canonicals, and similar settings unless a specific defect appears. Repeated technical changes add noise and can create new problems without addressing the reason the page performs poorly.

Use Search Console’s Performance report to identify the queries that generate impressions. Compare those queries with the page’s purpose, information, and format. Then assess whether the page answers the query completely and distinctively. Check for links from relevant pages on the site and references to the subject from credible external sites.

At that point, assess broader SEO factors. Check whether the page matches search intent and offers useful content. Review its internal links and the site's reputation. Then consider external references and the strength of competing results. A technically correct page still needs a reason to be selected for a particular search.

For time-sensitive pages, confirm that the information remains current and useful. Updating time-sensitive guides requires substantive changes; a new publication or update date by itself is insufficient.

Treat timing as evidence

A successful release does not produce an immediate change in search visibility. Google must recrawl the page, process the change, and decide whether it affects indexing or ranking. Search Console reporting also has its own delay. Google states that a recrawl request does not guarantee immediate inclusion.

Record when the fix went live and compare relevant data over time. Account for other site releases, ranking fluctuations, changes in competing pages, and shifts in search demand. Better performance after a fix deserves investigation, but sequence alone does not prove that the fix caused the improvement.

Questions site owners ask

Does a sitemap guarantee indexing?

No. A sitemap helps search engines discover URLs, but it does not guarantee that a search engine will crawl a URL, add it to its index, or show it in search results.

When a specific page is missing, check its HTTP response, internal links, robots directives, noindex tag, canonical URL, and status in Google Search Console’s URL Inspection tool. A URL in a sitemap still needs to be accessible, indexable, and selected as the canonical version.

Should every 404 be redirected?

No. Redirect a removed URL only when a closely relevant replacement exists. When the content is permanently gone and no suitable replacement exists, return a 404 Not Found response.

Sending unrelated URLs to the homepage or a broad category page frustrates visitors and leaves search engines without a clear signal about what replaces the old page. Google’s guidance on redirects and Google Search recommends redirects when the destination meaningfully replaces the original URL.

Does valid schema guarantee results?

No. Valid structured data supports eligibility for search features that a provider supports when the page also meets that feature’s content and technical requirements. It does not guarantee feature display, higher rankings, or citation in an AI-generated answer.

Review Google's current requirements for structured data features. Use the Rich Results Test for Google-supported features, and use the Schema Markup Validator to check whether markup follows Schema.org vocabulary.

How often should audits run?

Set the audit schedule according to how often the site changes, its technical complexity, and the cost of an indexing or availability failure. Run focused checks before and after a migration or major changes to templates, URL routing, robots rules, or JavaScript rendering.

Between full audits, monitor crawl, indexing, and server errors. Recurring monitoring catches new problems before the next scheduled review.

Technical SEO Audit Checklist

Trace each search stage separately: Check discovery, fetching, rendering, indexing, canonical selection, and search-result serving as distinct steps. A successful page request does not prove that a search engine indexed or displayed it.
Scope every finding: Record the exact URLs tested, method, date, evidence, and likely cause. Label inventories and samples clearly, since results from a sample do not establish how untested pages behave.
Fix confirmed blockers first: Prioritize access and indexing problems on important pages, then widespread URL, redirect, migration, and template defects. Match each fix to a repeatable check.
Verify after release: Retest the affected URLs under comparable conditions, record failures and exceptions, and allow time for search engines to process changes.
Separate eligibility from outcomes: Correct technical signals support crawling and indexing, while rankings, search-feature display, and AI-search citations remain separate outcomes without a guarantee.

FAQ

Does a sitemap guarantee that Google will index a page?

No. A sitemap helps Google discover URLs, but it does not guarantee crawling, indexing, or appearance in search results. Check the page’s response, internal links, robots and noindex directives, canonical URL, and Search Console status.

Should I redirect every 404 page?

No. Redirect a removed URL when a relevant replacement exists; otherwise, return an appropriate not-found response. Redirecting unrelated URLs to the homepage or a generic category leaves visitors without a useful destination.

What if Google crawls a page but does not index it?

A successful fetch shows that Google requested the URL, but it does not mean Google chose to include it in the index. Check rendered content, indexing directives, canonical signals, duplicate pages, and the URL Inspection result before changing the page.

How do I tell whether JavaScript hides important content from crawlers?

Compare the initial HTML response with the rendered page, checking the main text, links, title, canonical, and structured data. If important content appears only after a click, scroll, or other interaction, provide a stable crawlable URL or make the content available without that interaction.

Does valid structured data guarantee a rich result or AI citation?

No. Valid markup can support eligibility for a search feature that Google currently supports, but Google decides whether to display that feature. Markup does not guarantee rankings, rich results, or selection as a source in an AI feature.

How should I compare Core Web Vitals lab and field data?

Field data measures real-user experiences across varied devices and networks; lab data comes from a controlled test environment. Use field data to assess reported user patterns when available, and repeat lab tests under the same conditions to investigate causes. A passing lab sample does not establish that every page passes in field data.

What should I check if important pages disappear after a site migration?

Check the old-to-new URL map, redirect chains, final destinations, canonical URLs, internal links, sitemap entries, robots rules, and noindex directives. Crawl both old and new URL lists, then inspect affected URLs and Search Console reports after launch. Allow time for search systems to process the changes.

How often should I run a technical SEO audit?

Set the schedule according to release frequency, site complexity, and risk; there is no universal interval. Check before and after migrations or major changes to templates, routing, robots rules, or rendering, and monitor crawl and indexing errors between audits.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com