# Verifiable Content > Every page on this site is SHA-256 hash-verifiable and sealed into a witnessed, post-quantum-signed RFC-6962 transparency log. Verify any page yourself, in your own browser. [Home](https://rankshieldlegal.com/) / Verifiable content Powered by RankShield # Do not trust this page. Verify it. Every page on this site is hashed when it is built, and the manifest of those hashes is sealed into an append-only transparency log that is witnessed by nine independent parties and signed with post-quantum cryptography. You can check all of it yourself, right now, without trusting us and without an account. LIVE VERIFIER RUNS IN YOUR BROWSER PAGE PATH Verify this page Verify the log receipt Ready. Enter a path and verify. Try it on any page. The hash check runs in your browser using WebCrypto: no request to us is trusted. How it works ## Four layers, each checkable 01 ### Every page is hashed at build time When this site builds, it computes a SHA-256 of each page's plain-text version and publishes the list at /transparency.json. We hash the text rather than the HTML, because HTML churns with asset filenames on every deploy while the words stay the same. The hash moves only when the content moves. [transparency.json →](https://rankshieldlegal.com/transparency.json) 02 ### The manifest is sealed into a transparency log Those hashes are folded into one manifest hash, and that value is sealed into an RFC-6962 Merkle transparency log: the same append-only structure Certificate Transparency uses to keep certificate authorities honest. The receipt, including the inclusion proof, is published at /attestation.json. [attestation.json →](https://rankshieldlegal.com/attestation.json) 03 ### The log is witnessed, not self-certified A log you sign yourself proves nothing: you could show one history to one reader and a different history to another. This log's tree heads are co-signed by an independent nine-witness panel and are only accepted at a six-of-nine quorum. Each witness recomputes the root itself and refuses to sign a root that does not match. [the witness registry →](https://sea-shield-production.up.railway.app/api/helix/witnesses) 04 ### The signatures are post-quantum Witness co-signatures are composite: ML-DSA-65, the NIST-selected lattice signature, alongside classical Ed25519. Composite means both must hold, so the receipt survives a future break of either one. A signature is a promise about the future, which is precisely why it should not depend on a single mathematical assumption. [the current tree head →](https://sea-shield-production.up.railway.app/api/helix/log/head) The boundary ## What this does not prove A cryptography word in a marketing sentence is one of the easiest ways to imply more than you have. So, plainly: this proves **content integrity and provenance**. It proves the words you are reading are the words we published, and that the manifest was sealed into a witnessed log at a known time. It proves **nothing about rankings**, nothing about whether our advice is right, and nothing about the quality of the writing. A verified page can still be wrong. We are not claiming quantum-beacon binding either, because the beacon was reporting stale when this build ran, and a feature you cannot demonstrate on the day you claim it is a feature you should not claim. The point is narrow and worth it anyway: most claims on most agency sites cannot be checked at all. These can. For agents ## Machine-readable, by design An AI agent reading this site does not want our layout. It wants the content and a reason to believe it. Both are published as data. Every page has a plain-text twin at /.md, and any agent that sends an Accept: text/markdown header gets that twin instead of the HTML, which is ordinary HTTP content negotiation rather than a bespoke AI file. Every HTML response also advertises its twin in a Link header, so an agent can find it with a single HEAD request instead of parsing the page. The provenance is data too. [/transparency.json](https://rankshieldlegal.com/transparency.json) is the hash manifest, [/attestation.json](https://rankshieldlegal.com/attestation.json) is the signed receipt with its inclusion proof, and [/AGENTS.md](https://rankshieldlegal.com/AGENTS.md) describes the handshake in one page. An agent can fetch the twin, recompute the hash, check it against the manifest, and verify the receipt against a public endpoint, without any of it depending on our good behaviour. Verifiable content ## Questions about proving any of this What the cryptography does, what it does not, and how to check it without trusting us. **Answered directly.** JAMIE KLONCZ · SEO AGENCY NAPLES ************** ONLINE Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it. ← PREV NEXT → [REQUEST ACCESS →](https://rankshieldlegal.com/contact/) - **What does verifiable content actually mean here?** It means you do not have to take our word for what this site said. Every page is hashed at build time and the hashes are published. You can refetch any page, recompute its hash in your own browser, and compare. Separately, the manifest of those hashes is sealed into an append-only transparency log with an inclusion proof you can check against a public endpoint. If we quietly edited a page after publishing it, the hash would no longer match, and the change would be evident rather than invisible. - **Why would an SEO agency bother doing this?** Because our whole argument is that most agency claims cannot be checked, and that is a problem we should have to solve on ourselves first. Every statistic on this site names a primary source you can open. Every page can be hash-verified. The founder bio contains no award or press claim we cannot produce. Publishing verifiable content is the same standard turned inward. It is also useful: AI answer engines increasingly reward content whose provenance is legible, and a page that can prove it has not changed is a page that is easier to trust and cite. - **What does this prove, and what does it not prove?** It proves content integrity: that the words you are reading are the words that were published, and that the manifest of hashes was sealed into a witnessed, post-quantum-signed transparency log at a known point in time. It does not prove our advice is correct, that the content is any good, or anything at all about rankings. It is a provenance mechanism, not a quality claim. We would rather state that boundary plainly than let a cryptography word do marketing work it has not earned. - **Do I have to trust your site to verify it?** No, and that is the point. The page-hash check runs entirely in your browser using the WebCrypto API built into it. The receipt check goes through a proxy on our domain only because our security policy blocks browsers from calling other origins directly, but the verifier it forwards to is public and requires no key. The endpoint is printed on this page and inside attestation.json, so you can post the identical receipt to it yourself, from your own machine, and compare answers. A verification you can only perform on our site would not be worth much. - **What is RankShield and why is it involved?** RankShield is the verifiable-attestation platform this site is built on top of. Its core primitive is straightforward: sign any canonical statement, seal it to an RFC-6962 transparency log, and let anyone verify the receipt offline. This site uses it for content integrity. The same rail underpins the RankShield products, including the Shopify app, the WordPress plugin, and edge protection. We are associated with RankShield, which is why this site is an early adopter of its verifiable rail rather than a bystander to it. - **What about the quantum beacon I have read about?** The platform can bind a public quantum-randomness beacon into its signed tree heads as a freshness anchor. We are not claiming that here, because when we checked the beacon at build time it was reporting stale with no active binding. It would be easy to list it as a feature and unlikely that anyone would check. That is exactly why we do not. The claims on this page are limited to what the live endpoints returned when we looked.