Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The canonical tag is missing from the front page. However, all the inner pages contain it. Add the canonical tag into the front page:
This is a problem because right now all the Drupal sites have duplicate content on the front page. These are all duplicates:
http://example.com/
http://example.com/node
http://example.com/node/
The best solution would be to automatically 301 redirect http://example.com/node to http://example.com/, but until that the canonical tag is a good solution.
And if you promote your front page using Google Adwords, you end up with duplicate content, too:
http://example.com/?gclid=CJeVnMD30qUCFc0g3wodRT1Jjw
That's why the canonical tag is a must-have on the front page, and on all pages.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | drupal.canonical.8.patch | 3.39 KB | sun |
Comments
Comment #1
Bence commentedIt turned out that only the content types have the canonical tag, but every URL, generated by Drupal core or modules, must have the canonical tag.
Google doesn't like duplicate content: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=66359
They suggest to use canonicalization, or 301 redirect: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066
Now, Drupal doesn't use 301 redirect, I think the canonicalization method is easier to implement. There is a module called "Global Redirect", which I think should move into the core, because if fixes all the duplicate content issues in Drupal.
Currently Drupal is generating infinite number of duplicate content for each and every URL. For example, let's say this is the original URL, and I enabled clean URLs and custom paths:
http://example.com/?q=node/1.And my custom path for that node is
http://example.com/about.Then these are all duplicates, they must have a canonical tag which points to
http://example.com/about:(see #301373: Paths with non-ASCII characters do not redirect, create "duplicate content" issues)
http://example.com/nódé/1(see #301373: Paths with non-ASCII characters do not redirect, create "duplicate content" issues)etc.
This problem occurs at every URL generated by Drupal core or modules. For example, taxonomy links, user profile links, /tracker etc.
Inserting the canonical tag into all URLs solves this problem, and also provides a workaround for #301373: Paths with non-ASCII characters do not redirect, create "duplicate content" issues.
The front page has also duplicate content:
I think
http://example.com/node?page=2should point tohttp://example.com/?page=2.So the canonical tag must be inserted into all generated URLs. It would be also a good idea to move the functionality of the module "Global Redirect" into core.
Comment #2
XiaN Vizjereij commentedSubscribing
Comment #3
marcingy commentedThis is a feature request the concept of redirects is supported by the global redirect module so bumping to d8.
Comment #4
Bence commentedThat is (redirects) a separate issue. This issue is about inserting the canonical tags into all URLs. Content types have the canonical tag, so why not add it to all pages? This will resolve the duplicate content issue.
Even if you don't have a Drupal site, just let's say static HTML files, you still should use the canonical tag on ALL pages. And even if you redirect the pages to prevent duplicate content (for example, with Global Redirect), you still need the canonical tags, because of the tracking parameters, like Adwords campaigns, email campaigns, Google Analytics tracking links, affiliate program tracking URLs etc.
Take a look at Matt Cutt's blog: http://www.mattcutts.com/blog
EVERY URL contains the canonical tag, even category/tag archives, pages, posts etc.
This is a bug report, because Drupal generates infinite number of duplicate content. Is this the right behavior? I don't think so.
Question: the /node path should point (via the canonical tag) to / (the root), right? For example, this URL:
http://www.example.com/nodeshould have this canonical tag:<link rel="canonical" href="http://www.example.com/" />?If this issue was fixed, then the upgrade documentation should mention that before upgrading to Drupal 7, it is a good idea to disable modules which generated canonical tags (to prevent duplicate canonical tags), or disable that feature (canonical tag generation) in that modules before upgrading.
Comment #5
bojanz commentedDrupal 7 is done.
The only changes getting in right now are small bugfixes.
You have a feature request, because even though this is bad, it can be easily rectified with a contrib module.
Comment #6
Bence commentedBut someone added the canonical tag to content types, but forgot to add it to all URLs. Isn't it a bug? This feature is only 50% complete.
And there is no module right now which can generate proper canonical tags in Drupal 7, so looks like Drupal 7 will ship with weak SEO capabilities.
I don't understand why would this break contributed modules, since there is not a single module for Drupal 7 which generates canonical tags... And contributed modules should be already aware of the fact that Drupal core generates canonical tags on some pages.
Comment #7
Bence commentedComment #8
sunSomething along these lines might work.
Comment #10
Bence commentedAssigning this to 8.x-dev, I think this won't make into Drupal 7.
I don't understand that why is the canonical tag present only in nodes? Non-nodes have duplicate content, too.
Comment #11
matt bThe excellent metatag module (https://www.drupal.org/project/metatag) allows you to specify the canonical tag on individual pages. Fixed for Drupal 7, looks like the maintainers are porting this to Drupal 8. Suggest this can be closed?
Comment #25
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #26
smustgrave commentedSince there's been no follow up and this was a feature request going to close out. If still desired please re-open
Thanks all