After generating a canonical tag with the Canonical Tag Generator, three checks confirm the result is correct: the displayed normalized URL matches the real 200 page, the copied link element uses an absolute http or https href with ampersands escaped as &, and the served page exposes exactly one such element in its document head. The tool returns markup only; it does not edit your CMS template or verify how a framework renders the final document. Verification therefore happens in three places: the generator's own output, the source HTML you paste, and the live URL a crawler would fetch. Each layer answers a different question. The generator output tells you whether the browser's URL parser correctly stripped the fragment, normalized the host case, removed default ports, and escaped ampersands inside the href attribute. The pasted source tells you whether the tag sits inside the head and whether duplicates point to the same target. The live page tells you what crawlers and browsers actually receive after templating, redirects, or client-side rendering.
What "Checking the Result" Actually Covers
After you click Generate in the Canonical Tag Generator, the tool produces an HTML link element with an href pointing at the URL you typed. That single string is the "result," but it is the start of the check, not the end. Verification has to confirm that the markup the tool returned is well-formed, that the URL it normalized matches the real page you want search engines to prefer, and that the live document your CMS eventually serves contains exactly one canonical element with that href.
Many readers stop at copying the tag and assume a successful preview means the canonical will work in production. The generator runs entirely in your browser and never contacts the destination URL; it cannot tell you whether the page returns HTTP 200, whether a redirect sits in front of it, or whether your templating layer will overwrite the tag during render. Those are exactly the questions a quick post-generation check answers, and they are the questions this article is built around.
Read the Generator's Output Before You Trust It
Look at two parts of the tool's output: the normalized URL displayed as plain text and the escaped markup placed inside the link element. They should refer to the same address but with a small, expected difference. The visible URL keeps the ordinary ampersand because that is what users read; the attribute value uses & because that is the only valid form inside an HTML attribute. If you see a plain & inside the href, the generator did not escape the attribute correctly.
Next, confirm that the displayed normalized URL matches the address you intended. The browser's URL parser lowercases the host, removes the default port (80 for HTTP, 443 for HTTPS), and converts internationalized domain names to their Punycode form. If you typed https://Example.COM:443/Page, the generator will return https://example.com/Page. The host change is correct; the path case is not, because the parser preserves path case. If the displayed URL dropped a path segment you meant to keep, the parser saw something you did not, and that is worth fixing before you paste. A side-by-side review of input and output makes these rules easier to internalize; the Canonical Tag Generator normalization cheat sheet walks through the same expectations with worked examples.
Finally, confirm that the generator kept the fragment out of the target. According to Google's canonical documentation, fragment identifiers point to positions inside a document rather than separate network resources, so the tool removes them automatically. If you typed https://example.com/page#section and the output now shows https://example.com/page, that is the expected behavior. If you needed the fragment for a different reason, re-check whether fragment URLs are a valid canonical target in your situation rather than re-adding it by hand.
How to Check a Generated Canonical Tag
- Open the Canonical Tag Generator in your browser and type the complete preferred URL, including the scheme (http or https), host, path, and any intentional query string.
- Generate the tag and compare the displayed normalized URL with the address that actually returns HTTP 200 and shows the content you want indexed.
- Read the escaped markup line by line. Confirm the link element uses rel="canonical", the href attribute starts with http:// or https://, and every ampersand in the attribute is written as &.
- Copy the element and place it inside the HTML head of the page, not inside the body, and not inside a script that mutates after load.
- View the served HTML of the live URL with curl, browser "view source", or developer tools and confirm there is exactly one canonical link element with the href you generated.
- Visit each duplicate or near-duplicate URL, repeat the inspection, and confirm every duplicate's canonical points to the same target you checked above.
Inspect the Live Page After You Paste the Tag
The generator's preview proves only that the tool returned valid markup; it does not prove your CMS kept it. After pasting the element into your template, fetch the live URL with curl, with "view source" in the browser, or with your browser's developer tools, and search the document head for rel="canonical". Confirm three things in the response HTML: the canonical sits inside the head, not the body; there is no second canonical element produced by a plugin, theme, or HTTP header; and the href value is byte-identical to what the generator produced, with no extra query parameters added by your framework.
Browsers and crawlers receive the rendered HTML, not your template file. If your site is a client-rendered application, view the initial server response rather than the post-hydration DOM, because some frameworks strip or rewrite head tags after JavaScript runs. If a server-side header such as Link: <url>; rel="canonical" is also present, compare it with the in-document tag and confirm both point to the same address; conflicting signals between an in-document tag, an HTTP header, and a sitemap URL make the canonical preference weaker, not stronger.
Generator Output vs Live Page Signal
| Question | Generator Output | Live Page Signal |
|---|---|---|
| Is the href a complete absolute URL? | Always, since the tool rejects relative paths | Depends on the template; confirm manually |
| Are ampersands escaped as &? | Always | Confirm by viewing served HTML |
| Is the fragment removed? | Always | Confirm the served element contains no # |
| Is the host lowercased? | Always, per the browser URL parser | Confirm with developer tools |
| Is the canonical inside the head? | Cannot tell from the tool | Confirm by viewing served HTML |
| Is the target reachable as 200? | Cannot tell; the tool never fetches | Confirm with curl or a browser request |
| Is the canonical consistent across duplicates? | Cannot tell; one input at a time | Confirm by inspecting each duplicate |
The table makes the gap explicit: the tool guarantees the first four rows and tells you nothing about the last three. Those last three are exactly where post-generation checking earns its keep.
Common Verifications People Skip
- Checking the HTTP status of the canonical target. A 3xx, 404, or 5xx at the canonical URL defeats the signal because crawlers prefer resolvable pages.
- Looking at duplicate templates, not just the preferred one. A canonical works only if every duplicate consistently points to the same target; one outlier creates mixed signals.
- Reading the rendered HTML rather than the template file. Templating engines and client-side rendering can silently rewrite or duplicate head tags.
- Matching the canonical against sitemap entries and internal links. A canonical pointing at URL A while the sitemap and most internal links point at URL B dilutes the preference.
- Confirming there is no rel="canonical" injected by an HTTP response header that contradicts the in-document element. Crawlers combine the two, and conflicting values weaken both.
When to Re-Generate Instead of Re-Check
If verification reveals that the normalized URL does not match the page you intended, do not edit the generated markup by hand. Go back to the generator, correct the input, and regenerate, because hand-editing the href attribute is exactly how ampersand escaping, host case, or default-port handling gets broken. The same applies if the original input was a relative path or contained credentials; the generator rejected those inputs for a reason, and a hand-edited tag that "looks fine" can reintroduce the very problems the tool was built to prevent.
If verification shows the live page is serving the right tag but the page still appears under the wrong URL in search results, the issue is not the canonical itself. Per the Google Search Central canonical documentation, a canonical is a strong signal, not a guarantee; search engines combine it with redirects, sitemaps, internal links, and content evidence. A tag that passes every check in this article can still lose to a stronger redirect or to higher-quality content on the duplicate. In that situation the fix is at the routing or content layer, not at the tag itself.
If you're weighing options, How to Confirm Hreflang Tags After You Generate Them covers this in detail.