Canonical Tag Generator
Paste your preferred URL and get a ready-to-use rel="canonical" link tag, plus the HTTP Link header form, with warnings for the shapes that break canonicals.
- Free, no account
- No watermark
- No usage limit
About the Canonical Tag Generator
Paste the URL you want search engines to treat as the original and you get the rel="canonical" tag, ready to copy, free and with no sign-up. The part worth knowing is what happens between the paste and the tag.
30 URLs went through this generator while the page was being written. 17 came back with a tag and no comment. 13 picked up at least one warning, 8 of those in red. Not one of the 30 was refused, because a generator that argues with you instead of handing over the tag is no use on a deadline.
The other thing it does is leave your URL alone. Paste https://EXAMPLE.com/Page and the tag reads https://EXAMPLE.com/Page, capitals intact. Put the same string through a normal URL parser and you get https://example.com/Page back with the host quietly lowercased, which is a different string from the one you pasted, and search engines compare URL strings.
Switch the output format and the same URL comes back as an HTTP Link header, which is how you set a canonical on a PDF or any other file with no <head> to hold a tag. All of it runs in your browser. Nothing is uploaded, and it works offline once the page has loaded.
How to use
- Paste the URL you want indexed. The full absolute address of the page you want treated as the original,
https://and domain included. - Read the warnings before you copy. Red means the tag as written cannot name one fixed address. Amber means it will work but probably is not what you meant. Neither one stops the tag from being generated.
- Pick the format. Leave it on the HTML
<link>tag for a normal page. Switch to the HTTPLinkheader for a PDF, an image, or anything else served without HTML around it. - Copy it into the
<head>, then onto the duplicates. The same tag, pointing at the same URL, goes on every variant that should defer to this one. Google's documentation puts the element in the head section, so a tag that ends up in the body does nothing.
What it will not tidy up for you
Most code that touches URLs normalizes them. Hand one to a parser and it lowercases the host, drops a default port, resolves .. segments and punycodes an international domain, all before you ever see it. This tool does none of that, deliberately.
16 URLs of exactly that kind went in. All 16 came out byte for byte identical. Node's own URL parser, given the same 16, rewrote 8 of them.
| you paste | this tool writes | a URL parser returns |
|---|---|---|
https://EXAMPLE.com/Page |
https://EXAMPLE.com/Page |
https://example.com/Page |
https://example.com:443/page |
https://example.com:443/page |
https://example.com/page |
https://example.com/a/../b |
https://example.com/a/../b |
https://example.com/b |
https://müller.example/s |
https://müller.example/s |
https://xn--mller-kva.example/s |
https://example.com/café |
https://example.com/café |
https://example.com/caf%C3%A9 |
A normalizer turns müller.example into xn--mller-kva.example and /café into /caf%C3%A9. Both of those are correct encodings, and neither of them is the string you typed. Paste whichever form your site actually publishes, because nothing here converts in either direction. The tag you copy names the address you chose rather than the one a library preferred.
There is a cost to that and it should be said plainly. Paste a typo and the typo goes into the tag with no comment. The checking is about the shape of the URL, never about whether a page answers at the other end.
The warnings, and why three of them are red
There are 7 distinct messages that can appear under the field. 3 are red and 4 are amber, and as many as 4 of them can land on a single URL at once. The string http://example.com/a?q=<b>#top collects all 4 amber ones on its own.
The three in red are a relative URL, a protocol-relative URL, and a scheme with no domain after it. They are red because of what the tag does next, not because Google forbids them. Google's canonicalization documentation is unusually plain here: relative paths "are supported by Google", and the guidance to use absolute ones is a recommendation, with the stated risk being that you accidentally let a test site get crawled.
The failure that actually costs you is a quieter one, and it is easy to miss because the tag validates and Googlebot reads it perfectly well. Write your canonical as /page and every copy of it resolves against its own address:
- on
https://example.com/pageit resolves tohttps://example.com/page - on
https://www.example.com/pageit resolves tohttps://www.example.com/page - on
https://example.com/page?ref=newsletterit resolves tohttps://example.com/page
The www duplicate has just declared itself the original. Instead of three URLs collapsing onto one you get two competing canonicals and no consolidation, and there is no error anywhere to tell you so. A protocol-relative //example.com/page fails the same way across schemes. Loaded over http it resolves to http://example.com/page, loaded over https it becomes https://example.com/page, so one tag names two addresses depending on how the visitor arrived.
The four amber warnings cover an http URL on a site that probably serves https (Google lists a canonical pointing from an https page to an http one among its conflicting signals), a #fragment that search engines will ignore, leading or trailing spaces, and a URL carrying a < or a >.
Where the checking stops
11 deliberately broken strings went in with a scheme attached. 9 came back with no warning at all, including https://???, https://., https://-, zzz://example.com/page and https://example.com/my page. Node's URL parser throws outright on https://???. This one hands you a tag for it.
That is the honest limit. The test is whether the string opens with a scheme followed by ://, and everything after that is taken at your word. hello world gets the red relative-URL warning, it has no scheme to open with. Give a string a scheme and the checking largely stops, which is how https://??? sails through untouched.
The trade is real in both directions. No parser sits between you and your own address, so a URL your CMS genuinely serves that a strict parser would reject still comes out of here untouched. Whether that helps you depends on how much you trust the string you pasted.
The tag and the header are not the same string
Switching format does more than rewrap the URL. The two forms rewrite different characters, because an HTML attribute and an HTTP header field end on different things.
| character in your URL | in the <link> tag |
in the Link header |
|---|---|---|
& |
& |
& |
" |
" |
" |
' |
' |
' |
< |
< |
%3C |
> |
> |
%3E |
5 characters change in the tag form, 2 in the header form, and the 2 that appear in both columns are handled differently. & decodes back to a plain & when a browser parses the attribute, so the URL itself is unchanged and simply survives the trip through your HTML. In the header, < and > are the field's own delimiters, and a > sitting inside your URL would end the field early, leaving a header that points at a shorter URL than the one on your screen.
Paste https://example.com/a?q=<b>&r=1 and you can watch both happen. The tag comes out as href="https://example.com/a?q=<b>&r=1". The header comes out as Link: <https://example.com/a?q=%3Cb%3E&r=1>; rel="canonical".
One catch. Only 2 of those 5 rewrites raise a warning, the < and the >. Quotes and ampersands are changed with nothing said, so if you diff the output against what you pasted, that difference is deliberate.
Frequently asked questions
Does the URL I paste leave my browser?
No. The tag is built on your own device. There is no upload, no logging and no account. Everything the tool needs arrives with the page, so it keeps working offline once the page has loaded, and you can test that by dropping your connection and typing a new URL. Nothing is stored on your machine either: across 16 interactions in a row (7 URLs typed, the format switched, the same 7 retyped, then Reset pressed) it wrote nothing whatsoever to browser storage.
Should a page point its canonical at itself?
Yes, on every page you want indexed. Telling Google that /page is /page feels redundant, and the reason it is not is that you do not control every route to your own URL. Someone shares your link with ?utm_source= glued on, a crawler adds a trailing slash, your server answers on both www and non-www. A self-referencing tag on the clean version says which of those addresses counts, and without it any of the others can settle into the index instead.
Can one page carry two canonical tags?
It can, and then Google chooses for you. Google's own troubleshooting guidance names CMS plugins as a common cause of a canonical pointing somewhere you did not intend, and the classic case is a WordPress theme emitting one tag while an SEO plugin emits another, neither aware of the other. The docs also warn that using the tag and the HTTP header at the same time is more error prone, since it is easy to end up naming two different URLs. Check the rendered HTML rather than your template.
Google is ignoring my canonical. What should I check?
Four things, roughly in the order they usually turn out to be the cause. The tag sits in the <body> instead of the <head>, which is where Google's documentation puts the element. A script injected the tag after load rather than shipping it in the source. The target URL is blocked in robots.txt, so Google cannot fetch it to confirm the two pages match. Or the target's content is not close enough to the page carrying the tag, in which case Google overrides you and picks its own. View source on a cold load first, that clears the top two in about ten seconds.
Is a canonical the same as a redirect or a `noindex`?
No, and mixing them up is how pages disappear. A 301 moves the visitor to another URL. A canonical leaves the visitor exactly where they clicked and changes only which URL gets indexed. A noindex pulls the page out of search entirely, so putting noindex and a canonical on one page hands over two opposite instructions and it becomes a coin toss which is acted on. Google also ranks these by influence, and it lists redirects first, then the canonical annotation, both as strong signals, with a sitemap entry as a weak one.