Please remove the "disable comment pagination" notice

[blogtutor]

For many years, Yoast SEO has recommended disabling comment pagination. That may have been a valid recommendation years ago, but now disabling comment pagination can actually do more harm than good for SEO.

A large number of comments all on one page can create SEO issues, including:

• Slower page speed
• Diluted keyword density for the post content
• High DOM nodes on the page (reducing DOM nodes is an important GPSI/Lighthouse Opportunity -- and for pages with hundreds of comments, this makes an enormous difference).
• Overwhelming a mobile browser (if there are thousands of comments, it can cause it to bog down)

Pagination will also not hurt SEO, because the canonical URLs going back to the main article tell Google to spider the paged comments, but pass all SEO value (PR/link benefit and SERPs) to the main article and only show the main article for relevant Google SERPs.

Therefore, pagination should be enabled on any post or page that has a high number of comments on posts. Since it's set on a sitewide basis, though, most sites are probably better off with pagination enabled rather than disabled...which is the opposite of what Yoast SEO recommends right now.

Thanks!

[Djennez]

@jono-alderson this may be something for you to have a look at :)

[jonoalderson]

This is a really interesting challenge - thanks for doing such a great job of positioning it!

I do agree with all of the performance problems you outline, but I'm really uncomfortable with the idea of introducing pagination as a solution. I think that creating multiple 'copies' of a page in order to facilitate only paginate a secondary component of that page is a bad approach in multiple regards.

Whilst I agree that canonical URLs could reduce some of the SEO impact of that, we'd still be inflating the footprint of a site, and potentially sending confusing signals to search engines (and other external systems). It also raises some messy questions around things like XML sitemaps, schema markup, open graph tags, and more. Google's "one page = one thing" rule is a hard one to bend without making a mess.

I don't think that dilution of relevance is an issue unless comments are significantly off-topic - in which case it's an editorial/management problem, not a pagination problem.

I think that users should focus on solving the performance problems at the theme or plugin level, through a combination of:

• Using a more sophisticated system for processing and rendering comments than WordPress' native templating system (e.g., https://wpdiscuz.com/ or similar).
• Lazy-loading (either all comments, or just paginated sets) on the back-end (e.g., a JS trigger on scroll or on click to fetch more comments).
• Lazy-loading rendering on the front-end (see upcoming support in Chromium for managing rendering via content visibility).

Happy to discuss!

[blogtutor]

Thanks @jono-alderson . I appreciate your chiming in and your thoughtful reply.

I agree that Core's comment pagination can also be problematic. 😏

But if a post has many comments -- and a user doesn't take additional steps to mitigate them (such as WP Discuz or lazy loading; both great suggestions) -- the site would still be better off by keeping comment pagination enabled.

As a blanket recommendation from Yoast SEO, telling users that "as this is not needed in 999 out of 1000 cases" is misleading and unclear, and can still lead to doing more harm than good. That seems to be a made-up number, and without any explanation of what that 1 case out of a 1000 might be (and in my experience, it's a much higher number than that!), it does not help the user understand why they might want to take the advice to disable pagination, or to ignore it and keep pagination in place.

(Pagination also isn't all-or-nothing, of course, since the user can set the number of top level comments per page. That setting has a big impact as well, of course.)

So, until we solve these comment issues directly in core (perhaps we should propose improvements in 5.6?), I think the Yoast "recommended improvement" language should be removed, or at least be adjusted to be more useful and less dangerous, so users can make a more informed decision on their sites. Some ideas:

1. Replace the "999 out of 1000 cases" stat with a clear explanation why there's a recommendation to disable it. (Perhaps it could link to a blog post on the topic?)

2. Instead of blindly telling people to turn off pagination, which is indeed not good in every scenario, you could also recommend some of other strategies to mitigate issues from many comments, like the ones you mentioned above.

3. What if Yoast SEO analyzed the typical number of comments-per-post on the site, and compared that to the number of "top level comments per page" setting, and then customized the advice? For example, if a site typically gets 15 comments on a post, but has a handful of posts that have, say, 500 comments, and they have pagination set to 10 comments per page, it could recommend increasing the pagination to 20 per page, so that most posts would not be paginated, but the ones with many comments would be. (I'm not sure what the "upper limit" should be... I usually tell clients they should limit to about 20 top level comments per page -- and maybe lower if comments tend to get a lot of replies.) That could mitigate problems on the high-comment posts, but wouldn't change anything at all on the majority of posts on the page.)

Thanks!

[jonoalderson]

Good feedback! I agree that we should describe these scenarios, and help users in this situation to make informed decisions.

Unfortunately, the kind of analysis you're describing isn't possible for us without crossing some naughty data collection lines, and, it'd be a nightmare to work out what 'normal' looked like from such a data set without a ton of other metrics.

Could you let me know where the "as this is not needed in 999 out of 1000 cases" wording occurs / anywhere where you've seen text relating to the comment pagination option(s)?

I'm definitely in favour of us recommending lazy loading and adding some nuance!

[roam92]

It looks like nothing has happened here. No follow-through on the discussion above.

To the Yoast SEO team: Are you aware that, the way your plugin is currently implemented, all WordPress sites which do use pagination will end up with most of their comments being completely ignored by Google?

All comments not on the main canonical page will never be indexed by search engines, thus defeating the point and value of having all that unique content in the first place.

For all pages past the first page, Google Search Console will return "URL is not on Google: This page is not in the index, but not because of an error. Alternate page with canonical tag."

And poof, gone – all those comments fall into a black hole, never to be indexed again.

This happened to my site with 47,500 comments, and I'm only now realizing what went wrong and why the traffic fall-off...

Is this the result you want for your users? Is this improving your customers' sites with good SEO?

[tymwie]

Hello,

I noticed that when the division into pages of comments / opinions is enabled, despite the canonical attribute set in the code for the main page of the product, Google indexes all subpages with comments.

The canonical attribute is not a guarantee that the indexing robot will not index other subpages.

Therefore, in my opinion, there should be a function that will insert the noindex, follow attribute on paging subpages.

So if we have subpages:

https://domain.com/product-name/comment-page-1/ https://domain.com/product-name/comment-page-2/ https://domain.com/product-name/comment-page-3/ https://domain.com/product-name/comment-page-4/

then in the code we should have the code:

Then we are sure that Google will follow our recommendation and we will not have duplicates in the index as in the attached example above.

Does anyone have a solution for this problem?

[roam92]

Yes, The solution is for Yoast SEO to fix the plugin's improper handling of paged comments, so that:

1. All unique content is preserved and indexed properly, and
2. There is no duplication of content across comment pages.

It's definitely possible and not difficult; I wrote a code snippet to do it on my own site which fixed the problem with Yoast.

It is unreasonable for the plugin to simply drop the ball when comments break into multiple pages – some single posts have thousands of comments! Those shouldn't all be forced to be loaded on one page (performance).

The GHPSEO plugin figured this out over a decade ago – here is a screenshot of the settings page it had:

https://images2.imgbox.com/53/33/uXsP30ik_o.png

Further discussion here:

https://wordpress.org/support/topic/site-health-warning-for-paginated-comments/

[blogtutor]

Could you let me know where the "as this is not needed in 999 out of 1000 cases" wording occurs / anywhere where you've seen text relating to the comment pagination option(s)?

I'm definitely in favour of us recommending lazy loading and adding some nuance!

Hi @jonoalderson! Sorry for taking so long to get back to you on this.

The "This is not needed in 999 out of 1000 cases" is shown on the Site Health screen:

Perhaps the simplest solution here is simply to remove this recommendation from Yoast?

[blogtutor]

Also, these "Pagination Best Practices" directly from Google may be helpful?

https://developers.google.com/search/docs/advanced/ecommerce/pagination-and-incremental-page-loading

[feastdesignco]

I'm not sure I've seen any site with over 100 comments not have a "DOM nodes" warning in Pagespeed Insights. And 100 comments is not uncommon - many sites exceed 500+ comments for popular posts.

Pagination is a very useful tool and very well supported by Google.

Can we please get this notice removed?

[jonoalderson]

I'm definitely happy to remove the notice. Adding to the to-do list now. :)

[blogtutor]

Yay! Thanks @jonoalderson! :)

[roam92]

That's good to remove Yoast's dubious advice – but to truly do things properly, Yoast should not punt but rather fix how it currently mishandles paged comments.

[feastdesignco]

It looks like nothing has happened here. No follow-through on the discussion above.

To the Yoast SEO team: Are you aware that, the way your plugin is currently implemented, all WordPress sites which do use pagination will end up with most of their comments being completely ignored by Google?

All comments not on the main canonical page will never be indexed by search engines, thus defeating the point and value of having all that unique content in the first place.

For all pages past the first page, Google Search Console will return "URL is not on Google: This page is not in the index, but not because of an error. Alternate page with canonical tag."

And poof, gone – all those comments fall into a black hole, never to be indexed again.

This happened to my site with 47,500 comments, and I'm only now realizing what went wrong and why the traffic fall-off...

Is this the result you want for your users? Is this improving your customers' sites with good SEO?

I just checked this on a site I own, and content in comments found solely on page 2 are fully indexed and returned by Google.

Pagination and indexing of comments appears to work well on other sites.

Perhaps try reaching out to support for further troubleshooting as this may be a site-specific issue? And if the problem persists, maybe open a separate ticket. This ticket is specific to the removal of the pagination warning and not with how the pagination itself is handled.

[blogtutor]

We just had another client email us because she saw this warning in the health check...and we most certainly need her to keep comments paginated.

Minimizing DOM nodes is important for Core Web Vitals, and that includes with the upcoming Interaction to Next Paint metric. Paginating comments is one of the quickest/easiest ways to reduce nodes on a page (for posts with a lot of comments).

Per Google, at https://web.dev/optimize-inp/#minimize-dom-size --

When a page's DOM is small, rendering work usually finishes quickly. However, when DOMs get very large, rendering work tends to scale with increasing DOM size. The relationship between rendering work and DOM size isn't a linear one, but large DOMs do require more work to render than small DOMs. A large DOM is problematic in two cases:

During the initial page render, where a large DOM requires a lot of work to render the page's initial state. In response to a user interaction, where a large DOM can cause rendering updates to be very expensive, and therefore increase the time it takes for the browser to present the next frame.

@jonoalderson, can I give you a friendly nudge on this? Please? 😊