The Deployment Was Correct. The Canonical URL Was Not.

The Axiom Forge rebuild had passed its local checks and the new homepage was present at the origin. It contained the intended primary heading, commercial context and crawlable links. Yet a clean request to the canonical production address returned the earlier document: roughly a dozen useful words, no meaningful internal links and the old loading message. A person refreshing in a warmed browser could eventually see the right experience, while an external fetch—and therefore a search crawler—could receive something materially different.

That distinction mattered more than the visual bug. The page that exists in source control is not necessarily the page available for discovery. Search engines, social unfurlers, accessibility tools and AI retrieval systems begin with the delivered document. If the canonical response is thin or stale, the quality of the hidden release does not compensate for it.

The first useful evidence came from a controlled pair of requests. The plain canonical URL returned the old HTML. The same address with a unique query parameter returned the current document with its full heading, copy and links. Only the cache key changed. That isolated the delivery layer and stopped the investigation drifting into content, DNS, indexing or browser hydration.

A browser screenshot is weak evidence for this class of failure because hydration, service workers, local cache and previous navigations can all make the final screen look correct. We needed a ladder in which every step answered a narrower question. First: did the build contain the new document? Second: could the application produce it? Third: did the canonical public request receive it? Fourth: did a cache-busted request receive the same meaningful document?

The comparison focused on stable signals. Status code, document title, canonical URL, H1 text, visible word count and HTML link count are more useful than a byte-for-byte diff. A release may legitimately change a timestamp, request identifier or rotating label. Those details should not trigger a stale-cache verdict. A different title, missing primary heading or a drop from hundreds of words to a loading shell should.

The canonical root was being resolved through a static-asset delivery path that could preserve an older HTML document across the release. The fresh query variation did not reproduce the same stale result, which explained why the new code looked healthy in one path and absent in another. Purging the edge would have removed the immediate symptom, but it would not have made the routing rule safe for the next deployment.

The durable correction was to make the canonical homepage response explicit at the Worker boundary and to bypass document asset caching for HTML and discovery documents. Response headers were also made unambiguous: browsers may retain a document, but must revalidate it, while CDN-specific directives prevent an edge copy from masking a new release. Cloudflare documents the difference between no-cache, which permits storage with revalidation, and no-store, which bypasses storage. That distinction is small in syntax and large in operational effect.

We also removed the assumption that a cache purge is a release process. Purges are useful during diagnosis, but a system that requires a manual purge after every deployment has not described its cache policy correctly. The rule should express which assets are immutable, which documents must revalidate and which responses must never be stored at the shared edge.

The public checker now performs the investigation that exposed the issue. It retrieves a target page normally and with a unique cache-busting parameter, without executing client JavaScript. It extracts the title, meta description, canonical, H1 list, visible word volume, crawlable links, hreflang entries, JSON-LD types and Cloudflare cache status. It then compares the stable structural signals and returns one of three deliberately narrow verdicts: server-rendered, likely client-rendered or possible stale cache.

A verdict is not a ranking score. A sparse login screen may be correct, and a page with hundreds of server-rendered words may still be poor. The checker answers a delivery question: is a meaningful document present before JavaScript, and is the canonical response materially consistent with a fresh cache key? That makes it useful in deployment verification, technical SEO triage and issue reports where a reproducible link is more valuable than a screenshot.

Shared report URLs are rendered on the server. Opening a link therefore returns the verdict and measurements in the initial HTML instead of an empty form that waits for JavaScript. Those query variants use the tool page as their canonical URL so arbitrary user targets do not create an unlimited indexable URL space.

• Two bounded requests with a ten-second timeout
• A protected 1.5 MB maximum response size
• Manual redirect handling with public-address validation at every hop
• Per-IP rate limiting rather than one global quota
• No storage of target URLs or retrieved page content

Any server-side tool that accepts a URL can become a route into its own internal network. Validation cannot stop at checking that the input begins with http. Hostnames can resolve to private addresses, public endpoints can redirect to metadata services and IP addresses can be written in surprising forms. The checker resolves addresses before retrieval, rejects local, private, reserved and link-local ranges, allows only standard web ports and repeats validation after every redirect.

Tests cover localhost, IPv4 and IPv6 loopback, IPv4-mapped IPv6, cloud metadata addresses, non-web protocols and the decimal form 2130706433 that represents 127.0.0.1. A separate redirect test starts at a public address, returns a Location header pointing at a private target and verifies that the second destination is rejected before another page fetch occurs. This is not an optional hardening pass; it is part of the tool's core correctness.

Abuse controls are scoped per connection: ten checks per IP in a rotating ten-minute window. The database stores only an anonymous hash of the IP and time window with a count, then deletes expired buckets. It does not retain the original IP, target address or fetched HTML. That allows a public launch to serve many independent visitors without turning one busy user into a global outage.

The main process change is simple: production acceptance happens at the canonical URL. After a release, an external request must find the expected H1, a useful volume of server-visible copy, descriptive internal links and the correct canonical metadata. The same check confirms that a cache-busted response is materially consistent and that the HTML response is not an unexplained cache HIT.

A recurring monitor now checks the homepage, sitemap, key commercial pages, the tools hub and the checker itself. The monitor does not automatically rewrite content or purge caches; it reports the exact failed URL, expected condition and observed value. That separation keeps detection predictable and prevents a monitoring job from hiding the underlying problem with an unreviewed repair.

The larger lesson is not specific to one framework or CDN. Treat the delivery path as part of the product. Build output, runtime routing, cache rules and the final public response are separate systems. A release needs evidence from each one. The tool exists because our own deployment passed the first checks and failed the last—and because that final check should take ten seconds, not another investigation.