Scout Site Audit Free

Free, no signup. Crawl up to 150 exact-origin HTML pages, then check response status and headers for up to 100 exact-origin assets. Group raw-HTML SEO findings, inspect affected URLs, and export Pages, Links, Redirects, Assets, or Issues CSVs.

Built by Patrick Stox

Loads our intentionally broken kitchen-sink fixture so you can see Scout find real test defects. It only fills the URL; you still start the audit.
Manual URL seeds and local watchlists

Configurations and up to ten previous run summaries stay in this browser. Nothing runs on a schedule or in the background. Do not put secrets in URLs.

Checks run from our server; we fetch the URL you enter and don't keep the results. Up to 150 public HTML pages and status/header evidence for up to 100 exact-origin assets are retrieved through bounded, rate-limited proxies. Asset bodies are cancelled and never retained. Results stay in this browser unless you export them. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Site Audit Lite? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
  
 
Sample report Static report-shape example
82/100 raw-HTML site score
Crawled 24 of 31 discovered URLs (partial — page cap or policy exclusions would be named here).
title/missing · warn · 2 affected · checked on 24/24
Not evaluated: rendered JavaScript and AI checks.
This is illustrative output, not an audit of a real site and not a search-engine score.
 
 
 
How to use it
  1. Enter an HTTPS root, or an XML sitemap and select the sitemap option.
  2. Complete the anti-abuse check and start the bounded page crawl and asset-status phase.
  3. Read page and asset coverage separately, then expand issue rows.
  4. Export Pages, Links, Redirects, Assets, or Issues CSV evidence, print, or save a bounded snapshot.
  5. Use Page Report for a deeper single URL; Smart JS and Full Render are the rendered tiers.
 
 
 
     
     
       
What the results mean
  • Coverage — completed pages versus discovered inventory, with caps, aborts, exclusions, and trap sampling exposed.
  • Severity — detector-level pass/warn/fail prioritization.
  • Affected — pages with a non-pass finding among the pages where that detector ran.
  • Not checked / unavailable — missing evidence or deliberately excluded detector classes.
  • Cross-page findings — issues requiring crawl inventory or link relationships rather than one page.
 
How it works
A protected queue crawls exact-origin HTTPS pages from a root or bounded sitemap inventory, checks robots policy, normalizes discovered links, and caps trap patterns. Each usable raw response becomes a page record for deterministic detectors. The rollup preserves evaluation coverage and creates exportable issue evidence.
 
Features
  • Up to 150 fetched raw-HTML pages plus 100 status-only asset checks with abort support.
  • Root or sitemap seeding, robots checks, crawl-trap guards, and bounded asset extraction.
  • Grouped page, cross-page, and asset findings with separate coverage.
  • Pages, Links, Redirects, Assets, and Issues CSVs plus printable and comparable bounded snapshots.
 
Limitations
The crawl is bounded, raw-HTML only, and exact-origin; it cannot prove full site coverage or orphan status from a root crawl. Asset checks do not download or analyze file bodies, calculate transferred bytes, or evaluate third-party resources. Scout does not render JavaScript, honor crawl-delay, authenticate, run AI checks, call GSC, or emulate a search crawler’s index. Security findings are conservative review prompts, not proof that a site is exploitable.
 
Frequently asked questions
How many pages and assets does Scout Site Audit Free check?
It fetches up to 150 exact-origin HTML pages, then runs status-only checks for up to 100 exact-origin HTTPS assetsHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' extracted from complete raw HTML. Page and asset coverage are reported separately.
Does the audit render JavaScript?
No. Findings use fetched raw HTML. JavaScript-rendered content and links are explicitly not evaluated.
Does it obey robots.txt?
The page crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. applies Allow and Disallow rules for its crawl policy. This tool does not honor crawl-delayCrawl-delay is a non-standard robots.txt directive that asks bots to wait between successive page fetches to ease server load. Google has ignored it since September 1, 2019 and Yandex dropped it on February 22, 2018; Bing and many other crawlers still honor it, but Bing interprets the value differently than the plain reading., which it states in the scope note.
What is the raw-HTML site score?
It is a technical condition score derived from the impact and affected scale of evaluated, score-eligible page issues in the bounded sample. Asset findings are reported separately. It is not a Google score or a complete measure of site quality.
Can I compare audits over time?
Yes. Export a bounded local JSON snapshot and import it after another run. Coverage shifts can affect the comparison.
 
     
Next stepXML Sitemap Generator — generate the corrected version.

Explore more
ToolSEO Opportunity FinderToolLink AnalyzerToolInternal Link Cluster VisualizerArticleEcommerce SEO AuditArticleOn-Page SEO: Complete GuideArticleSEO Audit Checklist
 
 
 
Feature requests for Site Audit Lite
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
          
 
Common issues & how to fix them
 
 
 
 
 
Scout Site Audit Free · one finding
 
Page is blocked from indexing
 
Recommended action: Remove noindex from pages meant to be indexed, or keep it only when exclusion is intentional.
 
Fix principle: Remove every unintended noindex from its confirmed owner; absence of noindex is sufficient, while an explicit index directive cannot override another noindex because restrictive directives combine.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTML or HTTP response contains a noindex directive, including one added only by client-side script during rendering. The page is intended to be an indexable canonical URL. A robots meta tag or X-Robots-Tag intended to keep the page indexable is neutralized by a conflicting directive elsewhere, because directives combine using the most restrictive rule. Robots.txt disallows the URL itself, or disallows a resource the page depends on to render, so the crawler cannot reach or fully evaluate the intended indexable page.
 
Do not apply when: Exclusion is intentional for the page type, environment, or workflow state. The directive appears only on a noncanonical or otherwise ineligible URL. Robots.txt does not disallow the URL or the resources it needs to render, and the effective combination of every directive already resolves to the intended indexable state.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The application, server, or edge owner that emits the directive, or the robots.txt file at the site root
 
Steps
  1. Follow redirects, identify the exact owner of each unintended robots/googlebot meta or X-Robots-Tag noindex, and remove it only at that owner.
  2. Return the intended canonical page with a crawlable 200 response, align its canonical, and purge the caches that can retain the directive.
  3. If a robots meta tag or X-Robots-Tag is present but rendered ineffective by a conflicting directive elsewhere, remove the actual unwanted restrictive directive rather than adding a permissive one to compete with it — the most restrictive rule always wins. Google also honors a robots meta tag placed outside <head>, so an out-of-head placement is a specification and cross-crawler risk to correct, not by itself proof Google is ignoring the directive.
  4. If robots.txt disallows the URL itself, or disallows a resource (such as CSS or JS) the page needs to render its content, correct only the specific Disallow rule at the robots.txt file that owns it — keep the rule as narrow as its original intent, and remember Disallow blocks crawling, not indexing: a disallowed URL can still be indexed if discovered elsewhere.
  5. Keep the URL crawlable so Google can observe the removal.
  
Verify on this platform
 
  • After redirects and cache purge, inspect every robots and googlebot meta tag plus every X-Robots-Tag value on the final response.
  • Fetch and parse robots.txt for every group that applies to the relevant user-agent — Google consolidates every group matching the same user-agent token into one effective ruleset, though not every crawler does — and confirm the URL and its critical rendering resources are not disallowed.
  • Use Search Console URL Inspection’s live test on the production URL, then request indexing when appropriate.
 
Rollback
  1. Restore the prior directive or robots.txt rule if the page or a resource it needs was exposed or blocked unintentionally, then correct the underlying publication rule before trying again.
 
Caveats
  • Do not add index as a counter-directive: the most restrictive directive applies, so another noindex still wins.
  • The live test checks current accessibility; it does not guarantee selection, canonical choice, or indexing.
  • Google’s own parser combines every robots.txt group matching the same user-agent token into one effective ruleset, but many other crawlers and Robots Exclusion Protocol implementations honor only the first matching group — treat a directive split across groups as a real interoperability risk even when Google itself is unaffected.
  • If the page combines a canonical to a different URL with a noindex directive, remove the noindex only if this URL itself should be indexable; if the canonical target is the one meant to be indexed, keep the noindex here and verify the canonical target separately rather than treating its indexability as confirmed by removing this noindex.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Global Settings → Reading/blog_public, or the scoped plugin/theme callback that owns wp_robots
 
Steps
  1. If WordPress core globally owns the directive, confirm the scope and change Settings → Reading so blog_public permits search-engine visibility.
  2. For a scoped page-type or URL rule, identify and change the plugin or theme callback filtering wp_robots or invoking the core noindex behavior; do not invent a plugin UI.
  3. Purge page, object, host, and edge caches that can retain the old output.
  
Verify on this platform
 
  • While logged out, follow redirects and inspect all robots/googlebot meta plus X-Robots-Tag values on the final public response.
 
Rollback
  1. Restore the previous visibility or plugin setting if unintended pages become indexable.
 
Caveats
  • Do not use the global Reading setting to solve a scoped plugin or theme rule.
  • WordPress exposes the wp_robots API, but a third-party owner’s exact UI is not verified here.
  • Robots.txt is a separate control point from this meta/header directive — correct a Disallow rule using the generic-http-html guidance above regardless of which CMS serves the site.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Confirmed Response Header Transform Rule or Worker emitter
 
Steps
  1. Use Cloudflare Trace and configuration review to confirm which Transform Rule or Worker adds the final X-Robots-Tag and account for response-header rule ordering.
  2. Narrow or remove only that confirmed edge emitter; in a Worker, clone the response before modifying its headers.
  3. Purge the affected cache entries and leave any valid origin-owned robots header intact.
  
Verify on this platform
 
  • Compare origin and final Cloudflare responses after redirects, then confirm every final robots header and meta directive is free of unintended noindex.
 
Rollback
  1. Restore the prior edge rule if the scope change exposes excluded routes, then replace it with a narrower condition.
 
Caveats
  • Never blanket-delete a valid origin X-Robots-Tag when Cloudflare is not the confirmed emitter.
  • Later response-header rules can override earlier changes, so verify the final rule order and response.
  • Robots.txt is a separate control point from this response-header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: App Router metadata/generateMetadata, Pages Router next/head, or next.config headers()
 
Steps
  1. In the App Router, remove the unintended noindex from static metadata.robots or generateMetadata at the route that owns it.
  2. In the Pages Router, correct the owning next/head robots meta; for an X-Robots-Tag, correct the scoped next.config headers() rule.
  3. Deploy to the intended production environment and purge or bypass relevant caches before verification.
  
Verify on this platform
 
  • Inspect all final robots/googlebot meta and X-Robots-Tag values after redirects on the current production deployment.
 
Rollback
  1. Revert the route metadata, Head output, or headers() rule if the deployment exposes a route that should remain excluded.
 
Caveats
  • Vercel intentionally serves X-Robots-Tag: noindex for Preview Deployments and outdated Production Deployments; preserve that protection.
  • Do not diagnose an intentional preview response as a production metadata defect.
  • Robots.txt (a static file or a route handler such as app/robots.ts) is a separate control point from this metadata/header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned publication, visibility, or response-header control
 
Steps
  1. Ask the vendor to identify the exact global or scoped control that emits noindex and remove it only for the confirmed public canonical URL.
  
Verify on this platform
 
  • Follow redirects and inspect all robots/googlebot meta and X-Robots-Tag values on the final public response, then use the Search Console live test.
 
Rollback
  1. Restore the vendor visibility control if an unintended page becomes public while the owning rule is corrected.
 
Caveats
  • Do not add index to compete with a noindex emitted elsewhere.
  • Keep the URL crawlable long enough for search engines to observe the removal.
  • Ask the vendor to confirm whether it also owns robots.txt for the domain — a Disallow rule there is a separate control point from a meta/header directive.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Follow redirects and confirm a crawlable 200 final response with no noindex in any robots/googlebot meta or X-Robots-Tag value.
  2. Confirm the canonical points to the intended URL and relevant caches no longer serve the directive.
  3. Fetch and parse robots.txt for the applicable user-agent group(s) and confirm the URL and its critical rendering resources are not disallowed.
  4. Rerun SEO Site Audit Crawler, On-Page SEO Checker, Google Index Checker, Render Gap, or Robots.txt Tester (whichever surfaced the finding), and use Search Console URL Inspection’s live test for Google’s current view.
 
Escalate when
 
Escalate when page ownership or publication intent is unclear, noindex or a robots.txt Disallow rule is applied by multiple layers, or removing it would expose private, duplicate, or staging content.
 
 
 
 
 
 
 
Scout Site Audit Free · one finding
 
Canonical signals conflict
 
Recommended action: Return one canonical URL and make HTML and HTTP Link canonical signals agree.
 
Fix principle: Align every canonical signal for a page — the HTML <link rel=canonical>, an HTTP Link header, the post-render DOM, and each page's self-reference inside an hreflang cluster — on one confirmed intended URL; a conflict anywhere in that chain is resolved at its owning layer, never papered over by adding another canonical downstream.
 
 
 
 Implementation for your setup 
 
Confirm first: The page emits zero, more than one, or mutually disagreeing canonical signals across its HTML head, HTTP response header, or post-render DOM. A present canonical signal is relative, points to a URL that does not return a live 200 response, sits outside <head> where crawlers may not honor it, or only appears after client-side JavaScript runs.
 
Do not apply when: Exactly one absolute canonical URL is declared consistently across the HTML head, any HTTP header, and the rendered DOM, and that target itself returns 200. The apparent second reference is a distinct, valid annotation — an hreflang alternate, a pagination rel=next/prev, or another non-canonical link — not a competing canonical claim for the same page.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template, application server, or the layer that emits the HTTP Link header
 
Steps
  1. Enumerate every canonical signal for the URL — the HTML <link rel="canonical">, any HTTP Link: rel="canonical" response header, and the post-render DOM — and identify which layer emits each one.
  2. Choose exactly one intended absolute canonical URL per page and make every signal reproduce it verbatim; never declare a relative canonical, and never let a sitemap entry, redirect target, or hreflang alternate imply a different URL than the declared canonical.
  3. Correct or remove the emitting layer for any conflicting or duplicate signal at its source. Do not add a second, "corrective" canonical on top of an existing one.
  4. Confirm the canonical target itself returns a live 200 response on the protocol and host the site actually serves, not a redirect or error.
  
Verify on this platform
 
  • Fetch the raw response and inspect <head> for exactly one absolute canonical link, then check response headers for at most one agreeing Link: rel="canonical".
  • Confirm the canonical target itself returns 200 without redirecting, then use Search Console URL Inspection to compare the user-declared canonical against the Google-selected canonical.
 
Rollback
  1. Restore the previous canonical annotation or header if the correction points crawlers away from a URL that needs to stay indexed, then re-diagnose the true conflicting layer before trying again.
 
Caveats
  • A declared canonical is a hint, not a directive: Google may select a different URL as canonical for various reasons even when every signal you control agrees.
  • Don't specify different canonical URLs for the same page using different mechanisms (for example, one URL in a sitemap and a different one via rel=canonical) — the conflict itself is the defect, not the presence of any one mechanism.
  • If the page belongs to an hreflang cluster, each localized URL must canonicalize to itself (or its own best-language substitute), not to the primary-language version.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin/theme layer that has taken over the canonical tag
 
Steps
  1. Confirm WordPress core's native rel_canonical() output — hooked on wp_head — is the only source of the canonical tag, or that exactly one SEO plugin or theme has deliberately taken over that responsibility. Never leave two layers emitting a tag for the same page.
  2. If a plugin, theme, or manual template edit adds a second <link rel="canonical"> or a conflicting header, correct or remove it at that specific owning layer; do not add a third tag to compensate.
  3. Confirm the intended canonical target is the live, indexable URL the site actually wants, not a query-parameter, paginated, or otherwise non-canonical variant.
  
Verify on this platform
 
  • While logged out, view the public HTML source once and confirm a single <link rel="canonical"> matching the intended URL, then confirm no HTTP Link header contradicts it.
 
Rollback
  1. Restore the previous theme or plugin canonical configuration if removing a tag causes an unintended page to lose its canonical reference, then correct the true conflicting layer before trying again.
 
Caveats
  • Do not invent a specific SEO plugin's settings path: WordPress core exposes wp_get_canonical_url() and rel_canonical() on wp_head, but which plugin or theme, if any, has overridden that output is not verified here.
  • A page builder or headless WordPress frontend is owner-managed; use that system's own verified workflow instead of assuming core theme output controls the response.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.canonical / generateMetadata in the App Router, or next/head output in the Pages Router
 
Steps
  1. Set metadata.alternates.canonical (or the equivalent value returned from generateMetadata) to one absolute intended URL per App Router route; in the Pages Router, emit exactly one canonical <link> via next/head.
  2. Set metadataBase once at the root layout so relative canonical values resolve against the correct production host, instead of leaving canonical relative or inconsistent between preview and production domains.
  3. Do not also emit a second canonical tag from a component, a custom document, or an edge Proxy/Middleware response header once the metadata API owns the output.
  4. If the route belongs to an hreflang cluster, pair alternates.canonical with alternates.languages so each localized route canonicalizes to itself.
  
Verify on this platform
 
  • Fetch the deployed production route without executing JavaScript, confirm exactly one <link rel="canonical"> with the intended absolute URL, then rerun Canonicalization Checker or Render Gap on the same URL.
 
Rollback
  1. Revert the metadata export or route segment if the deployment changes the canonical for a route that needs to keep its prior target, then correct the actual conflicting layer before redeploying.
 
Caveats
  • metadataBase only fills in relative values; an already-absolute canonical value is used as-is and ignores metadataBase.
  • Confirm the production deployment domain matches the intended canonical host — a Preview Deployment URL is never the intended canonical target.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Online Store theme.liquid head output via the canonical_url Liquid object
 
Steps
  1. Duplicate the active theme and confirm theme.liquid emits exactly one <link rel="canonical" href="{{ canonical_url }}" /> in the head; Shopify's canonical_url object already resolves to the platform's intended canonical for standard product, collection, and content pages.
  2. If a second canonical tag is present — added by an app embed, a theme customization, or a duplicated snippet — remove it at that specific source rather than editing canonical_url itself.
  3. Preview representative product, collection, and content routes before publishing the corrected duplicate theme.
  
Verify on this platform
 
  • Inspect the published storefront response without browser execution and confirm a single canonical tag reflecting canonical_url on each route type.
 
Rollback
  1. Republish the previous theme if the corrected theme regresses canonical output or storefront functionality.
 
Caveats
  • These steps apply only to Shopify Online Store Liquid/JSON themes using the canonical_url object.
  • An app-owned storefront, a Hydrogen implementation, or an app that injects its own canonical tag is owner-managed; verify that system's own workflow rather than assuming theme.liquid is the only emitter.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits the canonical tag and header for the URL, then compare the user-declared and Google-selected canonical in Search Console URL Inspection.
  
Caveats
  • Escalate when the vendor cannot identify or expose the layer that emits a conflicting or duplicate canonical signal.
  • Do not accept a claim that the canonical is correct without one production-URL response showing a single agreeing signal.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the raw response and confirm exactly one canonical signal (the HTML tag and, if present, the HTTP header) names the same absolute, live URL.
  2. Confirm the canonical target itself returns 200 without redirecting.
  3. Compare the user-declared canonical against Google's selected canonical in Search Console URL Inspection.
  4. Rerun the finding's originating tool (Canonicalization Checker, On-Page SEO Checker, SEO Site Audit Crawler, Render Gap, Google Index Checker, or HTTP Header Checker) on the same production URL.
 
Escalate when
 
Escalate when ownership of the emitting layer is unclear, more than one system claims to own the canonical output, or Google's selected canonical keeps diverging from the declared canonical after every signal you control has been made consistent.
 
 
 
 
 
 
 
Scout Site Audit Free · one finding
 
Page returns a non-200 response
 
Recommended action: Restore an intended live page to 200, or update internal links to the correct final URL.
 
Fix principle: Trace every hop from the original URL to its terminus, diagnose which layer emits each hop (CMS canonicalization, application code, web-server config, edge/CDN rule, or vendor platform) and which specific failure shape is present — a loop, a dead end, an HTTPS-to-HTTP downgrade, an unexpected cross-domain change, a meta refresh standing in for a server redirect, or a chain exceeding the trace limit — then collapse the chain to a single server-side redirect straight to a confirmed live 200 destination at the layer that actually owns it. Never add a compensating redirect on top of a broken one.
 
 
 
 Implementation for your setup 
 
Confirm first: Tracing the URL through its actual HTTP responses shows more than one hop, a revisited URL (a loop), or a final hop that is not a live 2xx response. A hop changes protocol from HTTPS to HTTP, changes host/domain unexpectedly, or is implemented as an HTML meta refresh or JavaScript redirect instead of a server-side response.
 
Do not apply when: The URL resolves in a single hop directly to a live 200 response, with no protocol downgrade, no unexpected host change, and no loop. The extra hop is a single, intentional, same-domain, HTTPS-preserving server-side redirect with a live 200 terminus — a minor inefficiency, not a broken chain.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The observed HTTP response chain, traced hop by hop from the original URL
 
Steps
  1. Trace every hop from the original URL to its terminus, recording the status code, the Location header (or the meta refresh delay/target), and the scheme and host at each step.
  2. Classify the failure by shape before changing anything: a loop (a URL reappears in the trace), a dead end (the final hop is not a live 2xx response), a scheme downgrade (a hop changes https to http), a cross-domain change (a hop changes host unexpectedly), a meta refresh element standing in for a server response, or a chain that exceeds the checking tool's or server's hop-trace limit.
  3. Identify the exact owning layer for the hop that needs to change — CMS canonicalization, application code, web-server config, edge/CDN rule, or vendor platform — before editing anything; the same symptom can originate at different layers on different sites.
  4. Replace every intermediate hop with a single server-side 301 (or 308 only where the method and body must be preserved) directly from the original URL to the confirmed live 200 destination.
  5. Convert a meta refresh or JavaScript redirect to a real server-side redirect: Google treats an instant meta refresh as a permanent redirect and a delayed one as temporary, but recommends server-side redirects over meta refresh or JavaScript redirects whenever they are possible.
  
Verify on this platform
 
  • Re-trace the URL end to end and confirm exactly one hop lands on a live 200 response, with no loop, no downgrade, and no unexpected host change.
  • Confirm required query parameters are preserved in the Location value, and re-test representative internal links, canonical tags, and sitemap entries that pointed at the old intermediate URL.
 
Rollback
  1. Restore the previous redirect rule or response at the corrected layer if the collapsed redirect sends users or crawlers to the wrong destination or breaks a dependent flow.
 
Caveats
  • A redirect loop can span multiple servers or layers, each of which only sees part of the picture; fix the confirmed owning layer, not just the layer where the loop was first observed.
  • Keep the fix to the exact hop that is wrong — do not collapse an intentional, correctly-scoped single hop (for example a legitimate HTTP→HTTPS or trailing-slash redirect) into the change.
 
Official sources
 
 
Apache
 
Status: supported · Location: .htaccess or virtual host configuration (mod_alias Redirect/RedirectMatch, or mod_rewrite)
 
Steps
  1. Locate every Redirect, RedirectMatch, or RewriteRule directive that touches the URL's path, across every applicable config file and .htaccess in the path hierarchy.
  2. Replace the chain with a single `Redirect permanent` (or `RedirectMatch permanent` for a pattern-based path) issuing one 301 straight to the confirmed live final URL, and remove the superseded intermediate directive(s) entirely.
  3. For an HTTPS downgrade or a cross-domain hop, correct the target scheme/host in that same directive rather than adding another redirect after it.
  
Verify on this platform
 
  • Reload the corrected configuration, then re-fetch the URL and confirm a single 301 response with the corrected Location header lands directly on a live 200.
 
Rollback
  1. Restore the previous Redirect/RedirectMatch/RewriteRule directive(s) if the corrected chain misroutes traffic.
 
Caveats
  • Redirect directives take precedence over Alias and ScriptAlias directives regardless of the order they appear in the file, and can silently shadow a rule you expect to run first; when several Redirect/RedirectMatch directives apply to the same sub-path, the most specific path must be listed first.
 
Official sources
 
 
Nginx
 
Status: supported · Location: server/location blocks (return or rewrite directives)
 
Steps
  1. Find every `return 3xx` or `rewrite ... permanent`/`redirect` directive that touches the path, including one in a different server block for an old host or scheme.
  2. Replace them with a single `return 301 <final-url>;` (or 308 only where method/body must be preserved) in the location that receives the original request, and delete the superseded intermediate directive(s).
  3. When consolidating rewrite rules inside a location block, use the `break` flag rather than `last` — nginx caps internal rewrite/rewrite-loop processing at 10 iterations and returns a 500 once that limit is exceeded, which is a distinct cause of a chain-shaped failure from a client-visible HTTP loop.
  
Verify on this platform
 
  • Run `nginx -t` to validate the configuration, reload, then re-fetch the URL and confirm a single 301/308 response lands directly on the live destination.
 
Rollback
  1. Restore the previous return/rewrite directive(s) if the consolidated redirect misroutes traffic.
 
Caveats
  • nginx enforces its own internal rewrite-cycle limit (10 iterations, then a 500) separately from any client-facing redirect loop a browser or crawler reports; confirm which one is actually occurring before changing rules.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Bulk Redirects or Redirect Rules in the Cloudflare dashboard, or a Worker
 
Steps
  1. Confirm whether the hop is actually emitted by an edge redirect rule at all: Cloudflare Bulk Redirects and Redirect Rules run in the request-processing pipeline after WAF evaluation, so a rule can appear not to fire when a WAF action intercepts the request first.
  2. Consolidate every edge-owned hop for the URL into a single Bulk Redirect (or Redirect Rule) issuing one status code straight to the confirmed live destination, and remove the superseded rule(s) rather than layering a new one on top.
  3. If a Worker also emits a redirect for the same path, resolve the collision there — decide which layer owns the redirect and remove it from the other, rather than running both.
  
Verify on this platform
 
  • Purge the affected cache path, then re-fetch the URL through Cloudflare and confirm one edge-issued redirect lands directly on the live destination, unaffected by a WAF action.
 
Rollback
  1. Restore the previous edge rule (or disable the new one) if the consolidated redirect misroutes traffic or interacts badly with a WAF rule.
 
Caveats
  • Bulk Redirects are static and cannot use regex or string replacement; a pattern-based collapse needs a Redirect Rule or a Worker instead.
  • A WAF rule that blocks or challenges a request can prevent the edge redirect from ever running; that looks like a missing hop, not a rule conflict, until the WAF layer is checked.
 
Official sources
 
 
WordPress
 
Status: supported · Location: WordPress core's own canonical-redirect layer (redirect_canonical()) plus whichever layer implements the explicit redirect
 
Steps
  1. Determine whether one hop in the chain is WordPress core's own automatic canonicalization (`redirect_canonical()`, which normalizes trailing slashes, the www prefix, and stray query parameters such as `?p=` or `?page_id=`) rather than a manually configured redirect.
  2. If the automatic canonical hop is unwanted for a confirmed, intentional exception, remove it only for that case using the `redirect_canonical` filter — do not disable core canonicalization site-wide.
  3. WordPress core has no admin UI for managing arbitrary URL-to-URL redirects. Implement or correct the actual explicit redirect at the layer that owns it — the web-server configuration (see the generic-http-html, Apache, or Nginx guidance in this recipe) or a redirect-management plugin the site owner has already vetted. Do not invent a plugin's UI or assume one exists.
  
Verify on this platform
 
  • While logged out, re-trace the URL and confirm it reaches a live 200 response in one hop, and that WordPress core's canonical redirect no longer stacks with a separate redirect layer.
 
Rollback
  1. Remove the `redirect_canonical` filter override, or restore the previous server-config or plugin-level redirect rule, if the change misroutes traffic.
 
Caveats
  • Custom code that calls `wp_redirect()` with a user-supplied destination is vulnerable to open redirects; use `wp_safe_redirect()` instead for any redirect target that is not a trusted, hardcoded URL.
  • A page builder or headless WordPress frontend owns its own redirect behavior; treat it as platform-managed rather than assuming core template control applies.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify admin: Content → Menus → URL redirects
 
Steps
  1. Confirm the source path is actually broken (returns a 404) — Shopify's URL redirect feature only redirects from broken URLs, and rejects redirects from reserved paths (`/apps`, `/cart`, `/orders`, `/services`, `/shop`) and from fixed paths such as `/products`, `/collections`, and `/collections/all`.
  2. Point the redirect entry directly at the final live destination rather than at another URL that is itself a redirect entry, and delete the superseded intermediate entry so the store issues exactly one hop.
  3. If the destination page's visibility is later restored, Shopify automatically deletes the associated redirect entry; recheck for a reappeared broken URL after any content-visibility change that seems to have "un-fixed" a redirect.
  
Verify on this platform
 
  • Re-fetch the original broken URL and confirm it now redirects in a single hop to a live 200 destination.
 
Rollback
  1. Restore the previous redirect entry (or recreate it pointing at its prior destination) if the new destination misroutes traffic.
 
Caveats
  • Stores are limited to 100,000 URL redirects (20,000,000 on Shopify Plus); a large migration needs bulk CSV management rather than one-by-one entries.
  • An app-owned storefront or Hydrogen implementation is owner-managed and needs its own verified redirect workflow.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned redirect, routing, or CDN configuration
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to trace every hop for the URL and confirm the final destination is a live 200 response with no loop, downgrade, cross-domain change, or meta refresh substituting for a proper server-side redirect.
  
Caveats
  • Escalate when the vendor cannot expose or correct the exact rule emitting a hop.
  • Do not accept a claim that the URL "eventually works" as equivalent to a single verified hop landing on a live 200 response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Trace the full redirect chain end to end and confirm exactly one hop lands on a live 200 response.
  2. Confirm the redirect is a real server-side response (301/308 for a permanent move), not a meta refresh or JavaScript redirect standing in for one.
  3. Re-inspect the corrected URL with Search Console's URL Inspection live test after deployment.
  4. Rerun Redirect Checker (and Redirect Chain Mapper, where the finding came from it) against the corrected URL.
 
Escalate when
 
Escalate when the loop or chain spans multiple systems or owners, the intended final destination is not itself confirmed live, the fix would change authentication or session behavior, or a vendor platform cannot expose or correct the layer emitting the hop.
 
 
 
 
  
 
 
     
  •  Errors Title is missing Fix: Add a concise, unique title that describes the page, then rerun the check. 
  •  Warnings H1 is missing Fix: Add one descriptive H1 that states the page’s primary topic, then rerun the analysis. 
  •  Warnings Images lack alt attributes Fix: Add concise alternative text that communicates each meaningful image’s purpose. 
  •  Information Low visible text volume Fix: Review whether the observed text is complete for the page’s purpose. Add useful information only when something material is missing; do not pad the word count. 
  •  Warnings Meta description is missing Fix: Add a concise page-specific meta description to each affected template or page. 
  •  Information Structured data is absent Fix: Add supported structured data only to pages whose visible content satisfies the markup requirements. 
    •