Pagination canonical showing as blocked - Screaming Frog

datanerd

Running a technical audit and hit a weird one: paginated blog pages are showing as 'blocked' in Screaming Frog despite having self-referencing canonicals pointing to the root /blog/. We've noticed older blog posts haven't been indexing as much, so I started digging.

Subsequent pages like /blog/page/3/ up to /blog/page/14/ have this canonical setup:

And the actual URL pattern is: /ru/blog/page/3/?et_blog → /ru/blog/

Robots.txt isn't blocking anything. No robots meta tag either - I checked the source code of page 3 and it shows:

So it's explicitly allowing index. Someone in the thread asked about the trigger for pagination - I'm not sure what's driving the next-page event. The rel=next is present too:

Yet Screaming Frog still marks these as 'blocked'. Is this a non-issue or is something else causing Googlebot to treat these as non-indexable? Would love a second pair of eyes.

marketingmule

That doesn't look like self-referencing to me. Looks more like every paginated page is just pointing back to the root blog page.

cyberpunk

you're spot on about the issue. Each paginated page should carry its own self-referencing canonical. pointing them all back to page one cuts off Google's crawl path to the deeper pages - they won't get indexed, let alone rank.

from what I've seen, canonicalising to page one often creates orphaned content. The URLs that end up with self-referencing canonicals tend to appear on sites with stronger organic authority and a bigger share of keyword traffic. it's a pattern worth watching closely in your own crawl reports.

metricsmuse

Honestly, this is a really common one. The root of the problem is the canonical itself. When /blog/page/3/ points its canonical back to /blog/, Google sees page 3 as a duplicate of page 1 and basically stops bothering to index anything that only lives on deeper paginated pages. That fits perfectly with what you're seeing - older posts dropping out of the index.

Since around 2019, when Google deprecated rel=next/prev, the official guidance has been pretty clear: each paginated page should have a self-referencing canonical. So /blog/page/3/ should canonicalise to /blog/page/3/, not to /blog/.

In Yoast, you can fix this under SEO > Settings > Advanced (or Search Appearance > Content Types > the relevant post type in older versions). Look for the "paginated archive canonical" setting and switch it from "first page" to "self".

A couple of other bits worth checking while you're in there:

That ?et_blog parameter at the end of your URLs - if it's a Divi session param, you want the canonical to strip it. Yoast usually does this automatically, but double-check with URL Inspection to be sure.

The /ru/ language prefix in your example. If you're running multilingual pagination with WPML or Polylang, the canonical pattern needs to respect that language prefix. /ru/blog/page/3/ should self-canonical, not point to /ru/blog/ or, worse, just /blog/.

To verify, grab one of those older posts that isn't indexing and run it through GSC URL Inspection. If it says "Alternate page with proper canonical tag" and shows /blog/ or /ru/blog/ as the canonical, that's your smoking gun.

After you make the change, resubmit the paginated URLs via URL Inspection > Request Indexing to nudge Google into re-crawling with the new canonicals. Should sort it.

dailygrind

Honestly, I've run into this exact headache more times than I'd like to admit. A few things worth checking:

What actually triggers the next page? Is it a JavaScript click event, a standard <a> link, or something server-side? If it's JS-heavy, Google might not be executing that script and therefore never seeing the next page as a crawlable URL. Use Screaming Frog with JavaScript rendering to confirm.
"Robots isn't blocking" is dangerously vague. I've seen plenty of cases where someone swears robots.txt is clean, but they've got a noindex meta tag on the page parameter, or a disallow hidden in a wildcard rule they forgot about. Also check the X-Robots-Tag HTTP header - that one bites a lot of people. Crawl the paginated URLs via Ahrefs or GSC's URL inspection tool and look for any directive that would block indexing.
Self-referencing canonical with blocked indexing is a common contradiction. If you've set a canonical pointing to itself (which is correct for paginated pages), but Google can't actually crawl or index that URL, it'll show as blocked. The fix is either removing the block or adjusting the canonical chain to point to the main category page with rel="prev/next" if you're using that.
Check for server-level blocks too. Sometimes an IP or user-agent block at the server level (via .htaccess or nginx) stops Googlebot cold, even if robots.txt is wide open. You'd see that as a "blocked" status in GSC without any robots.txt rule matching.

Start by pulling the blocked URLs into a list, then run them through GSC's Live Test alongside a manual fetch with a tool like HTTPStatus.io. That'll show you exactly what Googlebot is seeing vs. what you think you're serving.

datanerd

right, this is a classic Yoast quirk that catches a lot of people out. the canonical pointing to https://this-site-dot.com/ru/blog/ from a paginated page (like page 3) means you're telling Google those paginated pages are actually the same content as the root blog index - that's a self-referencing problem in principle, because the canonical URL is different from the page URL. yoast does this by default: it consolidates pagination onto the first page of a series. that's fine for SEO intent, but it can confuse Google's indexation signals if your robots directives are inconsistent.

The index, follow meta tag says "go ahead and index this URL", but you're simultaneously sending a canonical pointing elsewhere. google tends to honour the canonical in the long run, but during crawl it might still flag the paginated URL as "blocked" if they detect a mismatch or if there's a redirect chain you're not seeing. i'd check a few things:

server-side headers: curl -I the paginated page and look for any 3xx redirects or X-Robots-Tag. sometimes caching layers inject a noindex that doesn't appear in the HTML source.
yoast's advanced settings: in the "Search Appearance" > "Taxonomies" section, make sure "Noindex for subpages of archives" is not accidentally enabled for post categories or tags. That'll inject a <meta name="robots" content="noindex"> into paginated pages, which overrides the page-level tag.
the rel="next" / rel="prev" markup - Yoast adds that, but if pagination chain breaks halfway (e.g., page 3 links to a non-existent page 4), Google may treat page 3 as a dead end and block it.

i've seen this exact pattern on B2B blogs where paginated listicles were intended to drive index coverage, but Google kept blocking them because the canonical was the root and the robots meta said "index". For a B2B demand gen site, that's a funnel leak - you want those deep pages indexed to capture long-tail queries. I'd either switch Yoast to use "show the original URL as the canonical" for pagination, or remove the canonical override entirely if you want each page indexed independently. Test with a single category and monitor coverage in GSC

dailygrind

interesting point. If the usual suspects-canonical tags, robot exclusions, hreflang mismatches-aren't the issue, we're probably looking at something a bit more niche. a few things I'd want to check in your crawl data (Screaming Frog or whatever you're using):

Response headers - specifically the X-Robots-Tag header. I've seen cases where a template-level noindex is injected via HTTP headers even when the meta robots tag looks clean. pull the full response for one of those blocked pagination URLs.
Internal link paths - sometimes the pagination URLs are linked with rel="nofollow" or use JavaScript that confuses the crawler. a quick crawl with JS rendering toggled on can reveal if the blocked state is a content delivery issue.
Google Search Console coverage report - if it's marked as "blocked by robots.txt", check that the user-agent in your actual robots.txt file isn't accidentally targeting the pagination pattern (I've seen Disallow: /*?page= trip people up).
Crawl depth - if those pages are deep in the architecture or only linked via faceted navigation, Google might treat them differently regardless of the self-referencing canonicals.

without seeing the actual crawl errors or server logs, it's tough to pin down. Happy to take a look if you can share a snippet of the relevant error details

pixelpusher

so you're on page 3, canonical points to root blog, and rel next points back to page 2? That's a bloody mess.

canonicalising paginated series to page 1 is lazy thinking - pure and simple. It defeats the purpose of pagination entirely. google already understands paginated content, you don't need to force everything back to the root like some ritual sacrifice. And that rel next pointing backwards? someone's been reading too many SEO blog posts written by people who've never actually scaled a real website.

Set your canonical to the current page, make rel next/prev sequential forward, and stop trying to game the system with shortcuts. it never ends well