{"id":2394,"date":"2018-06-05T10:34:26","date_gmt":"2018-06-05T10:34:26","guid":{"rendered":"https:\/\/www.searchviu.com\/?p=2394"},"modified":"2025-11-26T09:25:32","modified_gmt":"2025-11-26T09:25:32","slug":"javascript-canonical-tags","status":"publish","type":"post","link":"https:\/\/www.searchviu.com\/de\/javascript-kanonische-tags\/","title":{"rendered":"JavaScript SEO \u00dcberraschung! Google verwendet JS-injected canonical tags."},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tAt I\/O 2018, John Mueller and Tom Greenaway of Google gave an excellent presentation about SEO for JavaScript websites. During the talk, Tom Greenaway mentioned that Google does not look for canonical tags in the rendered HTML of a page. John Mueller later confirmed this statement several times on Twitter. The announcement sparked our curiosity, as we had previously conducted tests that had made us believe that canonical tags injected with JavaScript via Google Tag Manager DID work. We decided to set up a new test after the I\/O announcement. Here are the results.<\/strong>\n\nPlease note that this experiment is not about whether or not you should use GTM or JavaScript to inject critical elements into a page. The problem this test addresses is how Google deals with websites that depend on client-side JavaScript, a question that is extremely important in the day and age of popular JavaScript frameworks.<\/em>\n\nIn a rush? Jump straight to the\u00a0TL;DR section<\/a>!<\/strong>\n

Reviewing our \u201cCanonical tags via GTM\u201d test from last year<\/h2>\nGoogle\u2019s announcement surprised us, as\u00a0our previous tests<\/a>\u00a0had suggested that canonical tags and other SEO-relevant elements were always pulled from the rendered HTML as soon as it was available, and no longer from the HTML source document. Had Google changed the way they dealt with JS-injected canonical tags? Or had our interpretation of the previous test results been wrong?\n\nOur\u00a0canonical tag test result from last year<\/a>\u00a0was based on just one URL, so we had pretty weak evidence to support the claim that Google uses canonical tags that are injected with JS. The outcome of our test could have just been a big coincidence: Google might have decided to canonicalise our test URL to the target of our JS-injected canonical tag for other reasons.\n\nThis is a general problem when testing whether canonical tags work or not: You can only really use canonical tags between very similar pages that are likely to be canonicalised anyway. Otherwise, you risk your canonical tags being ignored altogether. On the other hand, when your pages with canonical tags are canonicalised, you can\u2019t be 100% sure that it\u2019s really due to the canonical tags.\n\nNote: If you\u2019re thinking \u201cWhy don\u2019t they just check the new GSC index coverage reports?\u201d, please be patient and read on. We\u2019ll get there.<\/em>\n\nIn last year\u2019s test, we injected a canonical tag into my author page on the English version of this blog, pointing to the main blog page. The author page has been canonicalised to the main blog page ever since, which can be verified by using an\u00a0info:<\/em>\u00a0search operator for the URL in Google (screenshot from the 11th of May 2018):\n\n\"\"<\/a>\n\nThe canonicalisation happened after we had injected a canonical tag with JS using Google Tag Manager and no other author or category pages on our website had ever been canonicalised in a similar fashion (with or without JS-injected canonical tags). Was this really just a coincidence?\n

Setting up our new test after I\/O<\/h2>\nAfter Google\u2019s announcement at I\/O, we wanted to replicate this exact result for more URLs, so we used JS and GTM to inject canonical tags pointing to the main blog page into four more category and author pages on our blog. We also made sure to leave two similar pages (my German author page and Michael\u2019s English author page) untouched, in order to have a control group of URLs that do not receive any canonical tags pointing to other pages and that thus should not be canonicalised by Google. If one of our control URLs was canonicalised to the main blog page without us injecting a canonical tag, this could mean that the test URLs were canonicalised for reasons other than the JS-injected canonical tags.\n\nHere are the four new test URLs for which we set up JS-injected canonical tags on the 11th of May, one day after Google\u2019s I\/O announcement\u00a0(all screenshots taken on the 11th of May)<\/strong>.\n\nEnglish \u201cSEO experiments\u201d category page:\n\n\"\"<\/a>\n\nEnglish \u201cSEO for website relaunches\u201d category page:\n\n\"\"<\/a>\n\nGerman \u201cSEO f\u00fcr Website-Relaunches\u201d category page:\n\n\"\"<\/a>\n\nMichael\u2019s German author page:\n\n\"\"<\/a>\n\nNote that the last test URL above, Michael\u2019s German author page, was canonicalised to his English author page at the time we set up the canonical tag, an issue we often see with different language versions of pages that don\u2019t have correct hreflang annotations. At the time of the screenshot, the hreflang annotations that can now be found on the page were missing. None of the other three pages were canonicalised at the time of the screenshots and, to our knowledge, they had never been canonicalised at any time in the past.\n

Waiting for the results<\/h2>\nAfter injecting the canonical tags, we waited\u00a0im<\/del>patiently. From our experience with previous tests, we knew that this needed time, as changes like these can take several months until they take effect. This is due to the fact that Google doesn\u2019t render pages as often as it re-crawls them without rendering, and the less important a page is, the less frequently it is re-crawled, and even less frequently rendered. If you inject an SEO-relevant element like a canonical tag, hreflang annotation, or a \u201cnoindex\u201d into the rendered HTML, but don\u2019t include it in the HTML source document, you have to be prepared to wait for a long time before you see results.\n

Google starts canonicalising our test URLs<\/h2>\nThe first of our test pages to be canonicalised to the target of our JS-injected canonical tag was our English \u201cSEO for website relaunches\u201d category page. We noticed the change on the 21st of May, 10 days after injecting the canonical tag. Here is a recent screenshot of the corresponding\u00a0info:<\/em>\u00a0search operator result:\n\n\"\"<\/a>\n\nNext, the English \u201cSEO experiments\u201d category page was canonicalised. This took significantly longer and we noticed the change on the 3rd of June, 23 days after injecting the canonical tag:\n\n\"\"<\/a>\n\nOn the 4th of June, 24 days after injecting the canonical tag with JavaScript, the German \u201cSEO f\u00fcr Website-Relaunches\u201d category page was canonicalised to the main blog page of our German website version:\n\n\"\"<\/a>\n\nOur fourth test URL, Michael\u2019s German author page, hasn\u2019t yet been canonicalised at the moment of writing this (25 days after injecting the canonical tag), but we are very confident that this page will also be canonicalised to the target of the JS-injected canonical tag within the next month or so:\n\n\"\"<\/a>\n\nUpdate (13th of June 2018):<\/strong>\u00a0This URL has now been canonicalised, 34 days after injecting the canonical tag.<\/em>\n\nLooking at this data, what do you think? Is it a coincidence that three of our four test URLs have been canonicalised to the targets of the canonical tags we injected with JavaScript? Or is Google still using JS-injected canonical tags, although they officially stated that this isn\u2019t the case? And if they do, why did they say they don\u2019t?\n\nBefore jumping to conclusions, let\u2019s talk about some other things that you should know about this test.\n

\u201cFetch and render > Request indexing\u201d in GSC doesn\u2019t seem to speed things up<\/h2>\nAfter injecting the canonical tags on the 11th of May, we performed a \u201cFetch and render > Request indexing\u201d for all of our test URLs:\n\n\"\"<\/a>\n\nOn the 22nd of May, we requested crawling and indexing for our main blog pages and all linked pages, as all of our test URLs are directly linked from the main blog pages. On the 1st of June, we performed another \u201cFetch and render > Request indexing\u201d for the three remaining test URLs that hadn\u2019t been canonicalised at that stage.\n\nWe know that \u201cFetch and render > Request indexing\u201d normally has an almost immediate effect when you use it to submit a new URL. It doesn\u2019t seem to influence the rendering of a page though, or at least not always. Our request on the 1st of June might have triggered the canonicalisation of two of our test URLs on the 3rd and 4th of June, but the one on the 11th of May certainly didn\u2019t have an immediate effect. Another factor might be that Google has to render a page more than once before it decides to pick up an injected canonical tag.\n

The new Search Console index coverage report does not tell the whole truth<\/h2>\nAt the time of writing this, our test URL from last year and our new test URL that was canonicalised on the 21st of May show up as \u201cSubmitted URL not selected as canonical\u201d in the new Google Search Console index coverage report:\n\n\"\"<\/a>\n\nThe two test URLs that were canonicalised on the 3rd and 4th of June still show up as \u201cSubmitted and indexed\u201d, because the data GSC shows is not up-to-date, but I expect them to show up as \u201cSubmitted URL not selected as canonical\u201d within the next few days.\n\nWhen Google finds a canonical tag on a page and respects it, we would expect the status of the URL in the new index report to be \u201cAlternate page with proper canonical tag\u201d. What is happening here?\n\nI have a simple theory to explain this: Google Search Console\u2019s index coverage report behaves in the exact way that Tom Greenaway and John Mueller announced at and after I\/O \u2013 It ignores canonical tags that are not in the HTML source document. So it reflects the behaviour that Google officially communicates, instead of the one that the results of this test reveal.\n\nSo Google Search Console has information about which URLs are indexed and it has a set of rules that it\u00a0assumes<\/em>\u00a0Google uses for indexing. Then it uses this set of rules to generate reports. When the set of rules GSC uses for generating its reports is different from the rules Google actually uses for indexing, the reports show false information.\n\nThis seems to be the case with JS-injected canonical tags: Google does use them to canonicalise pages, but GSC believes it doesn\u2019t. That\u2019s why these URLs end up being marked as \u201cSubmitted URL not selected as canonical\u201d instead of \u201cAlternate page with proper canonical tag\u201d. And this might also explain why John Mueller is 100% convinced that Google does not use JS-injected canonical tags:\n