The SEO Framework adds “noindex” to posts with multiple comment pages ??

Unfortunately, the problem is still there:

<meta name="robots" content="noindex,max-snippet:-1,max-image-preview:large,max-video-preview:-1" />

In the meantime, I had modified the “the_seo_framework_enable_noindex_comment_pagination” filter so that it reacted as I expected. I don’t know if this can help:

/**
 * Disable "noindex" robots meta added by The SEO Framework plugin
 * for the primary page of a single post/page that have comment pages
 */
add_filter('the_seo_framework_enable_noindex_comment_pagination', function () {
    return is_comment_page();
});

function is_comment_page(): bool
{
    if (
        !(is_single() || is_page())
        || get_option('page_comments') !== '1'
    ) {
        return false;
    }

    // if ?cpage=#
    if (!empty($_GET['cpage'])) {
        return true;
    } else {
        $permalink_structure = str_replace(
            $GLOBALS['wp_rewrite']->rewritecode,
            $GLOBALS['wp_rewrite']->rewritereplace,
            $GLOBALS['wp_rewrite']->permalink_structure
        );

        preg_match(
            sprintf(
                '#^%s/%s-([0-9]{1,})/?$#',
                ltrim($permalink_structure, '/'),
                $GLOBALS['wp_rewrite']->comments_pagination_base
            ),
            $GLOBALS['wp']->request,
            $matches
        );

        // if /comment-page-#
        if (!empty($matches)) {
            return true;
        }
    }

    return false;
}

I use the url to determine whether or not it’s a comments page that is displayed.

I don’t know if this is the best solution but it meets my expectations. If you’re interested, I can post the code on your GitHub repository.

Hi again, @dreamon11!

Thanks for the feedback. It took me a little longer to process.

I was under the impression you also used the comments block. This is why sharing the site URL is important for debugging/support. ??

The patch I added to TSF 5.0.6 only bypasses a specific WordPress Core bug where build_comment_query_vars_from_block() could run before wp_head(), which overrides cpage after the query was already established. It now appears that another function on your site is engaging the cpage query variable outside of the standard API.

You’ll find that set_query_var() is used sparsely in WordPress and only to patch one more lingering issue (coincidentally, also for cpage). This is in comments_template() (and wp_list_comments(), but only after comments_template() has done this).

With that, I think that your theme uses comments_template() and parses that before wp_head() runs, causing TSF to think we’re on a comment page.

This, then, is absolutely an edge case, but I think one more tiny adjustment in TSF could even account for that. Since you’re familiar with code, I want to ask you to adjust one single line in TSF at line 1201 of /inc/classes/helper/query.class.php: https://github.com/sybrew/the-seo-framework/blob/5.0.6/inc/classes/helper/query.class.php#L1201.

There, please change this:

if ( \has_block( 'core/comments', Data\Post::get_content() ) ) {

to:

if ( true ) {

It’ll make TSF always consider the bypass instead of only for the FSE bug.

It already has some preliminary checks engaged to ensure we’re on a comment page: get_query_var( 'cpage' ) is above 0, did_action( 'parse_comment_query' ) is true, and is_singular() is true.

Then, in the if ( true ) { branch, it’ll test if $wp_query->cpage is above 0, which affirms that cpage is adjusted via set_query_var().

Before testing if this does the trick, be sure to disable your custom filter.

Lastly, although unlikely, if you always see the /comment-page-#/ part in the URL, note that I still permitted /comment-page-1/ to be blocked via noindex because themes can behave unexpectedly by not always showing the content.

Hi @cybr,

In fact, I use comments_template() to display comments as you can see here: https://github.com/roots/sage/blob/5693139abc48ceb8893f45f07a8ade61f17846ac/resources/views/partials/content-single.blade.php#L22

When I change if ( \has_block( 'core/comments', Data\Post::get_content() ) ) { to if ( true ) {, noindex is no longer in meta robots:

<meta name="robots" content="max-snippet:-1,max-image-preview:large,max-video-preview:-1" />
<link rel="canonical" href="https://xxx" />

It displays <link rel="canonical" too.

With ?cpage=# or /comment-page-# in the URL, noindex is here but it is expected.

Excellent. Thank you for the follow-up!

I’ll deploy this improvement as a permanent fix in the next update.

Although pressing for the users experiencing this issue, I believe it to be a corner case and that it has already been resolved on your website. So, I won’t rush another update.

Thank you for your dedicated collaboration on this issue.

Hi @cybr,

TSF 5.0.6 is installed but the noindex in the meta robots is still here:

<!-- The SEO Framework?: par Sybre Waaijer -->
<meta name="robots" content="noindex,max-snippet:-1,max-image-preview:large,max-video-preview:-1" />

I always have to leave my custom filter to work around the problem:

/**
 * Disable "noindex" robots meta added by The SEO Framework plugin
 * for the primary page of a single post/page that have comment pages
 */
add_filter('the_seo_framework_enable_noindex_comment_pagination', function () {
    return is_comment_page();
});

The comment settings :

Hi again!

My schedule hasn’t allowed me to publicize the real fix yet. I usually release an update every 3 to 6 months, and I expect TSF v5.0.7 to come out in July 2024.

Thanks to your report, TSF v5.0.6 addressed the issue with Gutenberg and Full Site Editing, but unfortunately, not the custom scenario your site is working with. v5.0.7 will address the issue for everyone, including your site. So, the filter must stay in place until TSF v5.0.7.

Your experience is a corner case, meaning that this behavior only affects a few sites. Releasing an update is time-consuming and jeopardizes tens of thousands of users’ workflow. Due to caching issues and other odd server instabilities, there’s always something that goes wrong with an update for plugins at this scale — even if not a single line of code has changed. So, I pack as many improvements as possible with each update.

I’m sorry for the inconvenience. If the custom-filter workaround weren’t effective, I would’ve released v5.0.7 much sooner.

Thanks @cybr, I just wanted to keep you updated, in case you deployed the fix and it didn’t work as expected.

It’s not a big deal for me, the fix I share you works great ??

See you soon!