The canonical comes from one line of theme code
Blogger, Google's hosted blogging service on blogspot.com and custom domains, writes a self-referencing canonical on standard themes without any setup, and it drops parameters such as ?m=1 from the URL it names. The part worth checking is the custom or third-party theme, because that is where a second, conflicting canonical usually gets added.
Blogger themes are XML templates written in the platform's own layout language: <b:include> and <b:if> tags, data: values, and expr: attributes that evaluate them. The canonical is not a setting anywhere in the dashboard. It is output by a single include in the theme's <head>:
<b:include data='blog' name='all-head-content'/>That include bundles several head elements at once, among them the charset and viewport meta tags, feed links, and the canonical link. Delete it while trimming a theme and the canonical goes with it, along with everything else it printed. Keep it and add a canonical of your own, and the page now has two.
Observed on Google's own Blogger-hosted blog in September 2026, the output behaves as it should. The home page requested with ?m=1 declared the bare home URL as canonical, a 2020 post requested with ?m=1 declared the clean permalink, and the same post requested with ?utm_source=test&showComment=1 declared the same clean permalink. That blog's theme may be customized, so the observation is a strong indication rather than a guarantee for every stock theme.
Why Blogger needs a canonical more than most platforms
Few hosted platforms serve a single post at as many addresses as Blogger does, which is why the automatic tag earns its place.
?m=1: the mobile parameter, dating to Blogger's mobile templates of 2011. Modern themes are responsive, and norel="alternate"mobile link was seen on the desktop page, so in practice?m=1behaves as a parameter duplicate rather than a separate mobile site.?showComment=: comment permalinks that load the full post again.?gl=: a country parameter Blogger Help documents for viewing a country's version of a blog. From 2012, blogspot.com blogs were also redirected to country-code domains such as.co.uk; whether that still happens was not confirmed.- Label and search pages under
/search, which the default robots.txt disallows. These are kept out of the crawl rather than canonicalized, a distinction that matters if someone replaces the default robots.txt.
The canonical ties the parameter variants back to one permalink. The robots.txt rule handles archive-style listings. A theme or settings change that disturbs either one reopens the duplicate set.
Auditing a custom or third-party theme
Commercial and free Blogger templates often add their own canonical line for "SEO", without removing all-head-content. One public GitHub template contains both the include and this:
<link expr:href='data:blog.url' rel='canonical'/>data:blog.url is the URL of the current request, not its canonical form, so on a ?m=1 or comment URL the hand-written tag can name a different address than the one the include prints. Google's guidance is to have one canonical per page; two that disagree give it a reason to trust neither. Blogger Community threads about duplicate canonical tags suggest the pattern is common.
Search the theme HTML (Theme, then Edit HTML) for rel='canonical' and rel="canonical". The decision tree is short:
- If
all-head-contentis present, remove any extra canonical line. - If the theme deliberately omits
all-head-content, it needs exactly one hand-written canonical. - That hand-written tag should use the
.canonicalform of the URL value, not the raw one.
<link expr:href='data:view.url.canonical' rel='canonical'/>Treat that syntax with appropriate caution. Blogger's official data-tag reference does not list data:view.url or the .canonical suffix at all; the name comes from theme-developer references and working themes. Snippets from older tutorials that use data:blog.canonicalUrl rely on a tag those same references describe as abandoned in 2016, so copying them into a new theme is a gamble.
Some templates also run window.history.replaceState to hide ?m=1 from the address bar. That changes what a visitor sees, not what the server returns or what Googlebot fetches. It does nothing for canonicalization, and the canonical already points away from ?m=1.
Blogger settings that decide the canonical host
The canonical names whichever host the blog is served on, so the settings that change the host change the canonical. All of these live in Blogger's Settings:
| Setting | Effect on canonicalization |
|---|---|
| Publishing: Custom domain | Moves the blog to your domain; the blogspot.com address redirects there, which Blogger says can take up to 24 hours. Blogs cannot sit on a naked domain, so the served host is www or another subdomain. |
| Publishing: Redirect domain | Optionally redirects the naked domain to the www host, closing an obvious host duplicate. |
| HTTPS availability and redirect | Relevant only to custom domains; blogspot.com addresses are always HTTPS. |
| Crawlers and indexing: custom robots.txt | Replaces the default file, including its Disallow: /search line. |
| Crawlers and indexing: custom robots header tags | Controls noindex by page type; a wrong box on "Post and page tags" removes posts from the index rather than consolidating anything. |
| Errors and redirects: Custom redirects | Path redirects, with a Permanent option for a 301. |
A 2018 case study found all-head-content emitting an HTTP canonical while a blog answered on both HTTP and HTTPS without a redirect. That is the kind of drift the HTTPS redirect setting on a custom domain now prevents, and a reason to check the scheme in the canonical after any domain change.
Custom redirects are the setting most often misused. A Blogger Product Expert guide warns against using them to "fix" redirect warnings in Search Console, because redirecting ?m=1 to the permalink can create a redirect loop. robots.txt is equally wrong for the job; Google says plainly "Don't use the robots.txt file for canonicalization purposes."
Reading Search Console for a Blogger blog
Blogger owners often find hundreds of ?m=1 URLs in the Page indexing report and assume something is broken. It usually is not. Google's definition of "Alternate page with proper canonical tag" includes "a mobile version of a desktop canonical", which is precisely what a ?m=1 URL is. Seeing them there means the canonical worked. URLs listed under "Page with redirect" are, by definition, non-canonical addresses that redirect elsewhere and will not be indexed; after a move to a custom domain, the old blogspot.com URLs belong there.
Third-party posts claim that Googlebot Smartphone is redirected from the permalink to ?m=1, producing those redirect entries; Google has not documented that, so treat it as unconfirmed.
For a spot check, open three versions of one post: the permalink, the ?m=1 URL, and a ?showComment= URL. View source on each. There should be exactly one rel="canonical", and all three should name the same clean permalink on your primary host. URL Inspection then shows whether the Google-selected canonical agrees with the user-declared one. After adding a custom domain, confirm that the blogspot.com address answers with a 301 and that the canonical has switched to the custom domain.
What Blogger cannot do, and when to leave it alone
There is no canonical field in the post editor. Per-post options stop at custom robots tags, which appear only when custom robots header tags are enabled. Any different canonical has to be written as theme logic, a <b:if> condition that matches specific URLs and swaps the tag, and it affects every page the condition matches.
That rules out the common syndication case: pointing one republished post at its original on another domain. Hard-coding a URL-keyed conditional for each such post is fragile. For an occasional duplicate, noindex through the post's custom robots tags, or publishing the original somewhere with per-page canonical control, is the more maintainable choice.
For a blog on a standard theme, the right action is usually none. The platform's canonical already strips the parameters Blogger generates, and the most common way Blogger canonicals break is an owner or template editing the theme to improve them. Check once after every theme change, then leave it.
Frequently asked questions
Does Blogger add canonical tags automatically?
Yes, on themes that include <b:include data='blog' name='all-head-content'/> in the head, which standard Blogger themes do. The tag is self-referencing and omits parameters such as ?m=1. Custom themes that remove the include or add their own tag need checking.
How do I fix duplicate canonical tags in Blogger?
Open Theme, then Edit HTML, and search for rel='canonical'. If the theme keeps all-head-content, delete the extra hand-written canonical line. If the theme omits the include, keep exactly one tag built from the canonical form of the URL.
Why does Search Console show ?m=1 URLs on my Blogger blog?
Blogger serves every page at a ?m=1 address as well as its permalink, and the canonical points the parameter version back to the permalink. Listing those URLs under "Alternate page with proper canonical tag" is the expected result, not an error. Do not redirect or block them to make the report entries disappear.
Can I set a custom canonical URL for one Blogger post?
Not from the post editor; Blogger has no per-post canonical field. The only route is conditional logic in the theme HTML that matches that post's URL, which is fragile to maintain. For occasional duplicates, a per-post noindex through custom robots tags is simpler.
Is data:blog.canonicalUrl still valid in Blogger themes?
Theme-developer references describe data:blog.canonicalUrl as abandoned in 2016 in favor of the .canonical suffix, as in data:view.url.canonical. Blogger's official data-tag documentation lists neither, so test any hand-written tag by viewing source after saving the theme.
Does a custom domain change the canonical on Blogger?
It should. Once the custom domain is set, the blogspot.com address redirects to it and the canonical names the custom domain. Verify both after the change, including that the canonical uses HTTPS if you enabled the HTTPS redirect.