Forum Replies Created

Viewing 15 replies - 1 through 15 (of 249 total)
  • Plugin Author Pagup

    (@pagup)

    Hi Alex,

    Version 3.1.2 is out, and I’m adding a follow-up because it changes how the Free edition handles AI Search / Discovery crawlers, which was the point raised in this thread.

    Previous 3.x Free versions used a stricter, simpler preset model for AI crawlers, with more detailed control in Pro. We have replaced that with a more precise model.

    In the Free edition, you can now set a global policy for AI Search / Discovery crawlers: allow or block. That choice is now respected in the preview, when saving settings, and in the generated robots.txt.

    The plugin now separates AI-related agents into three practical groups, because they do not all serve the same purpose:

    • Training-related crawlers and controls, such as GPTBot, ClaudeBot, Google-Extended, CCBot, and AI2Bot.
    • Search / discovery crawlers, such as OAI-SearchBot, PerplexityBot, Claude-SearchBot, and Applebot.
    • User-triggered fetchers, such as ChatGPT-User, Perplexity-User, and Claude-User, where robots.txt behavior may vary by provider.

    The default follows that distinction: block training-related crawlers and controls while allowing AI Search / Discovery crawlers, unless the site owner chooses otherwise. This helps a site remain visible in AI-assisted search while still limiting training-related access where robots.txt is honored.

    Per-bot control and advanced governance options remain in Pro/Premium. The basic global AI Search / Discovery allow/block choice is now available in Free.

    For existing Free installations that may still have the earlier AI Search setting saved, 3.1.2 also shows a one-time notice in wp-admin so administrators can review the setting and either allow or keep blocking AI Search / Discovery crawlers.

    After updating, open Better Robots.txt, check the preview, and save the policy you want.

    Best regards,
    Pagup

    Plugin Author Pagup

    (@pagup)

    Hello,

    After auditing our plugin and checking with our community of more than one thousand users, no similar issue to the situation you mentioned with your sites has been reported to us.

    Are you sure you are not confusing our plugin with another one?

    Also, this sounds more like a situation involving a potentially abandoned plugin, or one outside the scope of WordPress.org, which is not at all the case with our plugin, whose latest update is recent.

    We regret that you are accusing our plugin of being the cause of your situation, even though no other similar case has been reported by the community. We remain convinced that this is a case of confusion with another plugin.

    Regards

    Plugin Author Pagup

    (@pagup)

    Hi Alex,

    You are correct.

    In the free version of the plugin, the AI crawler preset is intentionally restrictive and blocks most AI training bots by default. This preset cannot be modified in the free version.

    The ability to fully control AI crawlers, including allowing them to access and collect data from your website, is available in the Pro version of the plugin.

    So if your goal is to allow AI systems to train on your content, you would need to upgrade to the Pro version where the “Allow All AI Search” option becomes available and configurable.

    The free version focuses on providing a safe default configuration, while the Pro version gives full control over AI crawler policies.

    Hope this clarifies things.

    Best regards

    Plugin Author Pagup

    (@pagup)

    Hi Alex,

    Thanks for your question.

    There is a common misunderstanding around “AI bots” and what they actually do.

    Most AI crawlers (such as GPTBot or ClaudeBot) are primarily used to collect data for training AI models, not to “index” websites the way search engines do.

    In other words, allowing those bots usually means allowing your content to be used as training data, rather than improving visibility in AI systems.

    AI assistants that answer questions typically rely on search engine indexes or retrieve specific pages on demand. They don’t maintain a public web index in the same way search engines do.

    Version 3 of the plugin focuses on controlling those AI training crawlers. Blocking them does not necessarily prevent AI systems from accessing or referencing your site.

    If your goal is to allow AI training crawlers, you can adjust the preset rules in the plugin settings.

    Hope this clarifies things!

    Let us know

    Plugin Author Pagup

    (@pagup)

    Hi,

    We are working on it !

    We will let you know soon !

    Thread Starter Pagup

    (@pagup)

    Hello Yoast Team,

    I just wanted to confirm that the JavaScript error

    (0, t.select(...)).getPostType is not a function

    disappears completely after rolling back Yoast SEO to version 24.9.

    This means the issue was introduced in a later release — likely from v25.x onward.
    No cache, CDN, or other plugins are involved; the rollback alone resolves the problem instantly.

    You might want to review changes made in the recent versions regarding how the plugin enqueues its block-editor assets (yoast-seo-post-edit, etc.) even when Gutenberg is disabled.

    Best,

    Thread Starter Pagup

    (@pagup)

    Hello,

    Thanks for your reply. I can confirm that this issue is not related to caching.
    Here’s the situation in detail:

    • All plugins have been fully deactivated, except Yoast SEO, and the problem still occurs.
    • There is no caching active on the site: WP Rocket is disabled, no object cache is running, and Cloudflare’s cache has been purged.
    • The issue happens in the WordPress admin, when editing a page using WPBakery / Classic Editor, not Gutenberg.
    • The JavaScript console shows the Yoast script attempting to call

    (0, t.select(…)).getPostType is not a function

    which is a function that only exists in the Gutenberg editor (wp.data.select('core/editor')).

    • Since Gutenberg is completely disabled site-wide, this function cannot exist, and the error stops the Yoast metabox from loading properly.

    This means the problem is not cache-related, but caused by Yoast loading its block-editor (Gutenberg) assets even when the editor is disabled.

    Could you please escalate this to your technical team?
    Ideally, the Yoast script should check whether use_block_editor_for_post_type() returns true before loading Gutenberg-dependent bundles like yoast-seo-post-edit or yoast-seo-premium-post-edit.

    Thank you for reviewing this

    I’ll be happy to provide full console logs or stack traces if needed.

    Best regards,

    Plugin Author Pagup

    (@pagup)

    Hi,

    Thank you for contacting our support.

    Regarding your question, our plugin must remain active to ensure that all internal links created continue to function properly.

    This applies to both the FREE and PRO versions.

    Hope this helps.

    Best regards,

    Plugin Author Pagup

    (@pagup)

    Hello,

    We have received your various emails regarding this matter and are currently investigating the issue. For efficient handling of communications, we kindly ask that you avoid using multiple channels to contact us about this.

    We will respond by email as soon as we have an update.

    Best regards,

    Plugin Author Pagup

    (@pagup)

    Hi,

    Thank you for contacting our support.

    Could you please provide more details about your issue ?

    Let us know

    Regards

    Plugin Author Pagup

    (@pagup)

    Hi,

    Thank you for contacting our support.

    Regarding your issue, we have analyzed both pages:

    Are you not seeing these?

    Please try clearing your browser cache and let us know if the issue persists.

    Best regards,

    Plugin Author Pagup

    (@pagup)

    Hi,

    Could you forward to this email: support@better-robots.com the details of the email received from WordPress about this critical error?

    Thanks

    Plugin Author Pagup

    (@pagup)

    Hi,

    Regarding our plugin, Bialty uses the the_content filter, and in the case of WooCommerce, it also uses other filters for the product gallery images. Therefore, at the moment, it is not possible to add alt tags to related products, posts, the website logo, or images in the sidebar or footer, as these are outside the scope of the filters we use to add alt tags to images.

    That being said, considering how our plugin works—using either the “focus keyword” or the page title as the “Alt tag” for the image, such as for a product—from an SEO perspective, using the Alt tag of a specific product (its name, in this case) as the Alt tag for other products doesn’t make sense.

    This means that using the Alt tag corresponding to a product’s name (via its Meta tag keyword—aka Focus keywords, or the page title) for other products is not a good SEO practice. What matters to search engines is consistency and the reinforcement, through the Alt tag, of a page’s meaning. Diluting this understanding with a specific alt tag for different images other than the original product is not necessarily a good idea.

    For example, would it be relevant if, in a Google Images search, these other products appeared for a query related to your initial product?

    I hope this information helps you better understand how our plugin and Alt tags work for SEO.

    Best regards.

    Plugin Author Pagup

    (@pagup)

    Hi,

    Thank you for reaching our support.

    About this, please contact us at support@better-robots.com

    Regards

    Plugin Author Pagup

    (@pagup)

    Hi,

    Thank you for contacting our support.

    About your issue, we are looking at this …

    We will let you know as soon as possible.

    Thanks

Viewing 15 replies - 1 through 15 (of 249 total)