Crystal Ball checks covered

NON_200_STATUS, HTTP_REDIRECT_STATUS, REDIRECT_CHAIN, ROUTE_STATUS_UNSTABLE, ROUTE_FINAL_URL_UNSTABLE, ROUTE_STABILITY_PROBE_ERROR

Guide detail

Choose Your Technical Level

This setting applies to the meaning, causes, and fix sections. Your choice carries to other Fix Library guides on this device.

Practical explanations and page-specific steps. Recommended for most readers.

What the flag means

A normal, indexable page should usually return a 200 OK status. If Crystal Ball sees a non-200 status, a redirect, or a chain of redirects, it means the URL tested is not the clean final page. One redirect can be normal, especially from HTTP to HTTPS. A chain of redirects is messier: it makes users and crawlers take extra steps before reaching the real content.

If Crystal Ball reports route instability, the first request may have worked, but follow-up browser-like GET requests did not consistently return the same status or final URL. That can happen when clean URL rewrites, custom 404 handling, host-level canonical redirects, or cache layers disagree with each other.

Unintended errors and redirect chains delay access, complicate crawling, and make analytics and audit reports harder to interpret.

Common causes

Common causes include old URLs, changed slugs, deleted pages, protocol or host conflicts, trailing-slash mismatches, migration leftovers, redirect plugins, and platform-generated rules. On flat-file sites, physical directories may collide with clean URL rewrites, or the custom 404 document may be redirected instead of served directly.

What to check next

Check whether the issue appears on one page or every page using the same template. Review recent content, theme, plugin, deployment, and server changes, then compare the live output with a known-good page.

How to fix it

Confirm the warning first and make a backup before editing the live site. If the change involves templates, code, DNS, redirects, or server settings, switch to Intermediate or ask for help before proceeding.

  • Custom HTML/static: Test the URL with your browser and a header checker. Fix server rules, hosting redirects, or .htaccess so the page returns one clean final URL. Google's redirect guide is a useful reference.
  • Intermittent 404s or route instability: Compare the top-level document response in browser DevTools, not only curl -I. HEAD requests can look clean while browser GET requests expose a routing problem. Check whether a custom 404 page appears for fake URLs, whether diagnostic headers are present on failures, and whether host-level canonical/HTTPS settings are fighting with .htaccess.
  • Apache .htaccess clean URLs: Disable MultiViews, serve the custom 404.html directly, avoid rewriting the 404 document, and make sure clean URL rules do not collide with physical directories. If /education/ is rewritten to education.html, do not also deploy a public /education/ directory unless that directory has its own intended index file.
  • Cache and host settings: After changing rewrite rules, test in a fresh browser profile and check response headers. If valid pages sometimes show a bare server 404 instead of your branded 404, ask the host whether document-root routing, canonical URL settings, or edge/cache layers are bypassing the active site configuration.
  • WordPress: Check page slugs, permalink settings, SEO plugins, and redirect plugins. The Redirection plugin is a common option for managing 301s and 404s.
  • Shopify: Use Shopify's URL redirect manager when products, collections, or pages move. See Shopify URL redirects.
  • Wix: Use the URL Redirect Manager for changed page slugs or moved pages. See Wix 301 redirects.
  • Webflow: Use Webflow's 301 redirect settings and avoid chaining old URLs through multiple hops. See Webflow 301 redirects.

Micro case study: intermittent 404s on a static Apache site

A static site hosted on NearlyFreeSpeech.NET started returning alternating 200 OK and 404 Not Found responses for the same clean URLs. Browser refreshes, third-party checks, and repeated Crystal Ball probes showed the same pattern: valid pages worked on one request, then failed on the next. Successful responses included a diagnostic X-YSW-Htaccess-Version header. Failed responses did not, which meant the request was not reliably reaching the intended .htaccess path.

The fix was not to add more redirects. The stable version simplified the Apache rules and let the host handle what the host already owned:

  • Removed duplicate www to apex redirects from .htaccess after enabling NFS Canonical URL redirection.
  • Kept NFS HTTPS redirection in the hosting panel instead of stacking custom HTTPS rewrite rules.
  • Removed optional compression, expires, and complex conditional cache-header rules while testing route stability.
  • Served 404.html directly and kept the custom error document out of canonical URL rewrites.
  • Checked that clean URL rewrites did not collide with physical public directories.

After the simplified rules were deployed, repeated checks returned stable results: all sitemap URLs returned 200 OK, clean URLs consistently included the new diagnostic header, fake URLs returned the branded 404, and www URLs redirected to the canonical apex host. The lesson: if a host already provides canonical name and HTTPS controls, keep .htaccess focused on the few routing rules the site actually needs.

Need help?

If the fix gets murky, visit Support and send the details. Bug reports and Crystal Ball questions are free support. Implementation and development work may be paid support, but we will tell you clearly before anything becomes paid. No surprise invoices from the tower.