Canonical link for paginated blog: not SEO best practice


I’m using Quark Open Publishing theme v. 2.1.0 with latest Grav. I’ve noticed that the canonical link for page 2 (and following) of a blog is set as the blog main page.

This is not SEO best practice, so I’d like to know if this depends on Grav, or on the theme, and if someone has any suggestion on how to fix it, so that the canonical for that page is a self-referencing canonical, that is, the URL of that specific page (such as instead of

Thanks in advance.

@marcocevoli, Unfortunately the Pagination plugin doesn’t seem to provide the current page number.

As an alternative, you could try the Uri of the page and concatenate its params with the url of the page:

<link rel="canonical" href="{{ page.url(true, true) ~ uri.params }}" />

Which will give you for example (using the Quark blog skeleton):

<link rel="canonical" href="http://localhost/grav/site-blog/page:3" />

If the uri.params contains more parameters for the page, you might need to use some Twig logic to split the params.

When blog collection is using the ordering by: date with dir: desc, I suspect SEO will be hurt instead of improved.

With that ordering, the canonical link is not static but dynamic. Each new blog item will push a number of blog items (equal to the number of paginations, or 100/limit %) to pages with increasingly higher page numbers. Hence, the ‘canonical’ link indexed by Google will point to the wrong page sooner or later.

Only after Google has created a fresh index of the pages, the page numbers are in sync again.

A better way might be using a canonical link based on the static value of ‘year-month’, or ‘year’ (depending on the rate of new blog items). The Archives plugin might help with that.


Expanding on @pamtbaau’s advice, if you think about it, you want search engines to index your posts, not the lists of them.

Lists of posts are dynamic and contrary to the purpose of canonical links.

If I am searching, ideally I want to jump straight to the most relevant post or resource directly. Linking me to a list is just another scan and click, and there is the risk that the post is no longer on that page/list.

I think there is a case for having a canonical entry point for your blog (i.e. your blog homepage), which is likely to contain the latest posts. People might actually search for that (your blog).

So I would actually even leave paginated blog post listings off search indexes. Don’t provide a canonical link and use meta “noindex, follow”.

Also, having a syndicated Atom or RSS feed is probably better long term for search visibility.

What I stated in my first post is not my personal opinion, but the opinion of people working as SEO experts, based on evidence collected during several years of experience.

A list of posts is nothing than a page. This page has a URL. The problem lies in the fact that - currently - this page has a URL different than the canonical link written in its HTML code.

So you’re basically sending a contradictory message to search engines: there are a bunch of different pages (in content) with the same URL, the canonical to the main blog page. This results in penalization from Google and other search engines.

But, again, I’m not fighting battles here, just reporting what I read. :slight_smile:

I’m thinking it out logically for myself and putting myself in a searcher’s shoes. Be very careful what you read from SEO experts. You probably have more common sense than most of them.

It’s better to take a resource perspective when thinking about search, instead of a page perspective.

Perhaps I wasn’t clear enough. I didn’t say the canonical address should be the same for every blog post page (which was your original problem), I hoped to say it’s pointless hoping search engines index the lists, except for the entry page (“your blog”). Searchers want to land on the page with the information they searched for, and all of your individual posts will be indexed fully and more accurately if you put this metadata on them instead. Just think about that is all I’m saying.