Google Updates Rel=Canonical Documentation


Google updated their rel canonical documentation in order to clarify how Google handles the extraction of rel canonical annotations. The clarification is not meant to indicate a change in how Google handles rel=canonical annotations but rather to make it explicitly clear how Google processes them.

Canonical Link Relation – RFC 5988

Google’s documentation has always referenced RFC 5988 as the standard Google uses for how it uses the link relation canonical. 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 the standards related to HTML rel link attribute.

An HTML element is like a basic building block of an HTML webpage. 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 relationships between links on the web. This document describes a new type of such a relationship, “canonical”, to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content.

…Common implementations of the canonical link relation are to specify the preferred version of an IRI from duplicate pages created with the addition of IRI parameters (e.g., session IDs) or to specify the single-page version as preferred over the same content separated on multiple component pages.”

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

Changes To Canonical Documentation

The changes to the Search Central Documentation were specific to rel=”canonical” link annotations that are outside of the use case of specifying documents that are duplicative plus 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 word explicit:

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

While that change may seem trivial it’s actually the focus of the documentation change in that it makes it clear that Google is not deviating from the standards as laid out in the RFC 6596.

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

This is the new paragraph:

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

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

What that means is to not use “canonical” to specify something that is not a duplicative webpage, such as a page in another language or media but rather it’s better to use “alternate” instead.

This does not represent a change in how Google uses or ignores canonical or alternate link elements.

Google’s changelog documentation explains it:

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

Why: The rel=”canonical” annotations help Google determine which URL of a set of duplicates is the canonical. Adding certain attributes to the link element changes the meaning of the annotation to denote a different device or language version. This is a documentation change only; 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



Source link : Searchenginejournal.com

Social media & sharing icons powered by UltimatelySocial
error

Enjoy Our Website? Please share :) Thank you!