Updates to Google Rel=Canonical Documentation

Updates to Google Rel=Canonical Documentation

Google has updated its rel canonical documentation to clarify how Google handles the extraction of rel canonical annotations. The clarification is not intended to indicate a change in the way Google handles rel=canonical annotations, but to make it explicitly clear how Google processes them.

Canonical Binding Relationship – RFC 5988

Google’s documentation has always referenced RFC 5988 as the standard Google uses for how it uses the canonical link relationship. The RFC is a standard published by the Internet Engineering Task Force (IETF) that defines specifications for various Internet and networking technologies, in this case standards related to the HTML rel link attribute.

An HTML element is like a basic block of an HTML web page. An element can be extended with an attribute. In this case, the Link element is modified by the Rel attribute.
RFC 6596 defines the rel link attribute as:

“RFC 5988 specifies a way to define the relationships between links on the web. This document describes a new type of this relationship, “canonical”, to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicate content.

… Common implementations of the canonical binding relationship are to specify the preferred version of an IRI from duplicate pages created by adding IRI parameters (eg, session ID) or to specify the version of a single page as preferred over the same content separated into multiple component pages.”

This means that the canonical link element specifies when another document is duplicated (duplicative) and which is the preferred original. These are the parameters Google used to process the canonical link element.

Changes to canonical documentation

Changes to the search core documentation were specific to rel=”canonical” link annotations that are outside of the use case of specifying documents that are duplicates and some minor and trivial changes to the page.

Google changed the following sentence:

“Google supports rel canonical link annotations as described in RFC 6596”.

The change is limited to adding the explicit word:

“Google supports explicit rel canonical link annotations as described in RFC 6596”.

While this change may seem trivial, it is actually the focus of the documentation change, as it makes it clear that Google is not deviating from the standards established in RFC 6596.

The next change is the addition of an entirely new paragraph.

This is the new paragraph:

“rel=”canonical” annotations that suggest alternative versions of a page are ignored; specifically, rel=”canonical” annotations with hreflang, lang, media, and type attributes are not used for canonicalization.

Instead, use appropriate link annotations to specify alternate versions of a page; for example link rel=”alternate” hreflang for language and country annotations”.

This means don’t use “canonical” to specify something other than a duplicate web page, such as a page in another language or medium, but rather use “alternative”.

This does not represent a change in the way Google uses or ignores canonical or alternative link elements.

from Google change log the documentation explains it:

“Clarify extraction of rel=”canonical” annotations.
What: Clarified that rel=”canonical” annotations with certain attributes are not used for canonicalization.

Why: rel=”canonical” annotations help Google determine which URL in a set of duplicates is the canonical. Adding certain attributes to the link element changes the meaning of the annotation to indicate a different device or language version. This is just a documentation change; Google has always ignored these rel=”canonical” annotations for canonicalization purposes.”

Read Google’s updated documentation:

How to specify a canonical with rel=”canonical” and other methods

Featured image by Shutterstock/Kues

[ad_2]

Source link

You May Also Like

About the Author: Ted Simmons

I follow and report the current news trends on Google news.

Leave a Reply

Your email address will not be published. Required fields are marked *