Short answer: This is not “you typed the code wrong.” It means the checker did not read the expected content at the expected location. Test reachability, then exact content, then caching.

The message shows up in three different situations. Identify yours first.
Case 1: site ownership verification
A platform asks you to upload a file or add a tag, then fetches it.
- Open the exact URL in a private window. If it fails there, nothing else matters yet.
- Check the status code. It must be
200. Many frameworks redirect unknown paths to the homepage and still return 200 — it looks reachable but serves the wrong body. - Check
Content-Type. A text file served as HTML, or forced as a download, fails the check. - Filename case. Linux is case sensitive;
Verify.txtandverify.txtare different files. - No extra bytes. A BOM added by your editor, a trailing newline, or the content wrapped in HTML all break an exact match.
- CDN cache. You deployed, but the edge still serves the old 404. Purge, then retry.
- Crawler reachability. Firewalls, geo-blocking,
robots.txt, or a forced login wall will stop the checker.
Using the meta-tag method? Make sure the tag is inside <head> in the server-rendered HTML. Most checkers do not run your JavaScript.
Case 2: sender ID or template registration
If sending fails with “signature or template not deployed,” what you sent doesn’t match what was registered:
- The sender ID must match character for character, including bracket width.
- Template variables must match in count and order.
- Sending while the registration is still under review counts as not deployed.
- Placement (prefix or suffix) is part of the registration too.
Background: what is an SMS sender ID.
Case 3: webhook signature verification
When a third party calls your endpoint and reports a bad signature:
- Wrong key — a staging secret shipped to production.
- Your canonical string differs from the docs in parameter ordering or encoding.
- The timestamp is outside the accepted window and gets treated as a replay.
- A gateway or load balancer rewrote headers, so the signature no longer matches the original request.
See API key security.
Universal checklist
| Check | How to confirm |
|---|---|
| Reachable | Private window, plus a different network |
| Returns 200 | Read the response headers, not the rendered page |
| Exact content | Diff character by character against the source |
| No BOM or stray newline | Inspect with a hex or plain-text editor |
| Cache purged | Append a random query string and refetch |
| Not blocked | Disable geo-rules and login walls, retry |
Wrap-up
The error always reduces to “couldn’t read it” or “read something different.” Prove external reachability first, diff the bytes second, blame cache last.