Crystal Ball checks covered

NON_200_STATUS, HTTP_REDIRECT_STATUS, REDIRECT_CHAIN, ROUTE_STATUS_UNSTABLE, ROUTE_FINAL_URL_UNSTABLE, ROUTE_STABILITY_PROBE_ERROR

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.

This matters because broken, slow, or confusing URL paths waste crawl time, weaken user experience, and can make reports harder to trust.

Common causes

Common causes include old URLs, changed slugs, deleted pages, HTTP-to-HTTPS redirects, www/non-www conflicts, trailing slash mismatches, migration leftovers, redirect plugins, Shopify product changes, Wix automatic redirects, Webflow 301 rules stacked on top of hosting rules, physical directories colliding with clean URL rewrites, or a custom 404 document that gets redirected instead of served directly.

How to fix it

  • 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 the best starting scroll.
  • 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.