Saša

Problem is in the priority because Yoast itself uses this filter. You should increase default prio to higher (eg. default 10 -> 20 or even higher) to avoid conflicts with other code/plugins:

add_filter('wpseo_canonical', 'xxxxxxxxxxxx', 20);
https://developer.wordpress.org/reference/functions/add_filter/

I’ll try to quickly answer in couple tips:

• Make sure that both WordPress and Site URLs point to correct secure URLs – https://wordpress.org/support/article/changing-the-site-url/
• Purge all cache which you have installed (I see LiteSpeed cache, but maybe there is other caching)
• Divi themes/builder force deprecated Yoast’s sitemap cache (into transients – disabled by default into Yoast) – https://yoast.com/help/sitemap-does-not-update/:
  

  Please disable the sitemap feature, clear cache, and enable the sitemap feature to force the sitemap to rebuild.

@illuminice Not directly, but I’m “contributor” on Github and I’ve created many pull requests there. I know well Yoast codebase,… I’m trying to support WP/Yoast community when I have spare time.

One of my clients had similar issue (but only pages were affected) with BuddyPress/GamiPress. If same URL works, but after N hours it doesn’t work then I don’t think that Yoast is cause. Some issues on github are related to “plugin update” where “wrong rewrite rules” are saved during update process.

I’ve created custom plugin which logs all 404s (together with WP query details) + all changes related to rewrite rules. After couple weeks we were able to find exact root of cause.

I still can’t conclude more details.

When you see “false 404” did you try to “flush rewrite rules” (Settings ➔ Permalinks ➔ just click on save) and refresh same URL? Also, you can try PHP snippet from https://wordpress.org/support/topic/recurring-404-error-for-all-pages-but-not-posts-or-bbpress-topics/ which will do same.

You can try to temporary remove line which adds the filter pre_handle_404(the method register_hooks in wordpress-seo/src/integrations/front-end/handle-404.php ). If it works then some plugins use/add feeds on wrong way. I’ve created this class and I may help in this case.

@gnuworld You can find more details (and PHP snippets) – https://github.com/Yoast/wordpress-seo/issues/387, but you need to modify these examples.
The easiest way is the filter wpseo_exclude_from_sitemap_by_post_ids which will exclude everything except products from particular product category. It should work. I never saw issues related to this filter.

It’s possible than your website uses nginx server or .htaccess isn’t writeable (if it’s apache server – https://wordpress.org/support/article/using-permalinks/#creating-and-editing-htaccess). You should contact your host for more details (about server type). Website is behind CF, so I can’t see “server signature”.

There is an issue related to “forcing trailing slash”:

$ curl -k -i https://furlytics.com/sitemap_index.xml
HTTP/1.1 301 Moved Permanently
Date: Thu, 15 Jul 2021 06:22:29 GMT
Server: Apache
...
X-Redirect-By: WordPress
...
Location: https://furlytics.com/sitemap_index.xml/
...

When I try to access via query string (/?sitemap=1) then the sitemap index works (same for sub sitemaps).

I didn’t similar behavior, but my websites run on dedicated servers.

Which is version of WP Bakery? It could be an issue with outdated version. The latest is 6.7.0 – https://kb.wpbakery.com/docs/preface/release-notes/

It’s old code and I agree that should be improved.

However, functions _wpseo_activate and _wpseo_deactivate are called only at the installation (or manual deactivation/activation of the plugin). WP update doesn’t run these functions (I didn’t notice similar behavior with WPSC). So, I think that it isn’t root of cause of your issue.

Updating some (Yoast) options could run clear_cache too… You should try to catch when purging was triggered. WPSC offers good debug log. Depends on cache plugin (W3TC or WPSC), you should try to find out debug back-trace when this function called.

You can create feature request on Github.