Alright, so I was doing a TCO assessment for a client looking at switching from Semrush, and part of that is verifying the data integrity of the shiny new tool they'd be buying into. Naturally, I'm poking at Ahrefs.
Here's a fun one I stumbled across that seems like a straight-up bug, or at least a massive "gotcha" in their 'Ranking Pages' report. If your site uses paginated content (think /blog/page/2/, /category/thing/page/3/), Ahrefs appears to be double-counting—or maybe infinitely counting—the keywords and traffic for the *first* page of the pagination series onto every subsequent paginated page.
Example: My test site has a blog. The main blog page (/blog/) ranks for, say, 50 keywords with an estimated traffic of 200. The paginated page (/blog/page/2/) should rank for virtually nothing—it's just an archive list. Ahrefs' report claims /blog/page/2/ also ranks for ~50 keywords and also gets ~200 traffic. So does page 3, page 4, etc. The keyword lists are nearly identical.
This isn't just a quirk of their estimation model. It's assigning ranking positions and search volume to URLs that logically cannot and do not rank for those terms. It inflates the perceived value and "ranking pages" count of a site in their system dramatically. Run this report for a large publisher with heavy pagination and you'll see a comically inflated picture of their organic footprint.
I've replicated this on three different sites now. The immediate concern is data cleanliness—what else is being smeared across URLs? The broader concern is the classic vendor lock-in play: you're sold on a platform using impressive-looking reports, only to find the foundational data has critical, undisclosed flaws. Then you're stuck because "all your historical data is there."
Has anyone else tripped over this? Or found a setting buried deep in a config that supposedly "fixes" it? I'm not holding my breath.
☕
Buyer beware.
Oh, that's a nasty find. It completely skews any traffic aggregation or page value analysis you'd pull from the report. I've seen similar logic errors in other platforms during migrations, where canonical signals or pagination tags aren't parsed correctly, causing the "parent" data to bleed into all "child" entries.
It reminds me of a CRM data migration where contact duplicate detection rules were buggy - every linked record inflated the primary contact's activity count. The core issue is often the same: flawed relationship mapping in the backend.
For your TCO assessment, this is a huge red flag for data integrity. I'd document this specific case and test it against Semrush's handling of the same paginated pages. If Semrush gets it right, that's a concrete, quantifiable advantage to include in your report.
migrate with care