Sybre Waaijer

Hello!

I just created a new up-to-date snippet for exactly your use case: https://gist.github.com/sybrew/6fac62935cc66f2f027ae4b251c58bc0.

It contains two versions: One that extracts HTML and one that takes the text as-is.

(Where do I place filters?)

I hope this helps!

Hi Shaun!

Sorry, I missed your message earlier.

TSF doesn’t support separate sitemaps per post type. However, if you disable the optimized sitemap, WordPress’s built-in sitemap takes over, which does organize entries by post type.

That said, search engines don’t care about sitemap organization—they just look for links. A sitemap with 400 or even thousands of entries won’t cause issues; search engines process these routinely.

TSF sorts entries by last-updated date, so recently changed properties will appear at the top. If older links fall off the sitemap, that’s fine: search engines are already aware of them. For most sites, sitemaps are needed only to discover new and updated content, not as a complete index.

Still, due to popular demand (coming from news networks), I’m working on monthly/yearly sitemaps for archival support (#649); that won’t address per-post-type separation, but it will enable listing all posts of a site.

Hello! I also saw your email about this–let’s continue in this topic.

You can find the plugin privacy information here: https://tsf.fyi/privacy/plugin

In short, you do not need to list The SEO Framework in your privacy policy:

1. Cookies: TSF does not create or use any cookies.
2. Visitor data: TSF does not collect, process, or share any visitor data.
3. DPA: No personal data processing occurs on our behalf.

If you also use our Extension Manager or Troy Client plugins, the same applies to visitor data. Extension Manager or Troy Client may send non-identifiable data (like its version number) for plugin updates, but this does not involve visitor information and doesn’t require GDPR disclosure.

If you have any other questions, let me know! Cheers 🙂

• This reply was modified 3 weeks, 5 days ago by Sybre Waaijer. Reason: formatting

Ah, oops! This little quirk slipped my mind. It’s been nearly 7 years since I discussed this.

Facebook (the leading proponent of Open Graph) does not support en_AU and used to display errors if you used it. TSF falls back to the first match in the supported list for en_, which is en_GB.

Here’s some background: https://wordpress.org/support/topic/oglocale-problem/.

Here you can find a more current list of locales Facebook supports in one part of its ecosystem — still no Australian English: https://developers.facebook.com/docs/messenger-platform/messenger-profile/supported-locales/.

Diving deeper into it again, I found:
1. New updated docs: https://developers.facebook.com/docs/sharing/webmasters#markup
2. Which links to: https://developers.facebook.com/docs/javascript/internationalization#locales
3. Which proposed to test for: https://connect.facebook.net/en_AU/all.js
4. Which then shows en_US in the header comment.

A supported language, such as en_GB, shows exactly that in the header: https://connect.facebook.net/en_GB/all.js.
So, I must conclude that en_AU is still not supported.

I just tested en_AU on my site, and also a few others that definitely do not exist, and Facebook no longer complains about it to the user. Though I think it’s safer to stick with the fallback, you can use this filter to force en_AU:

add_filter(
    'the_seo_framework_meta_render_data',
    function ( $tags_render_data ) {

        if ( isset( $tags_render_data['og:locale'] ) )
            $tags_render_data['og:locale']['attributes']['content'] = 'en_AU';

        return $tags_render_data;
    }
);

(Where do I place filters?)

• This reply was modified 4 weeks ago by Sybre Waaijer.

Hello!

I understand! You can keep the questions coming!

1. The Query Alteration feature won’t affect Google Search-embedded results; it only affects WordPress’s on-site search results. You can toggle off “Enable search query alteration” to hide the relevant toggles from the page SEO settings.

2. When importing data to TSF, you must not use any other SEO data transport plugin besides that of Extension Manager. The reason is that we need to perform syntax transformations before storing them; otherwise, you get wrong results.

Unfortunately, when I wanted to implement support for AIOSEO, they changed their data structure, so I held off. The dust seems to have settled, and I have it planned for the next large update (probably March 2026).

Until then, you could use Yoast SEO to import from AIOSEO. You should delete AIOSEO’s data via Yoast SEO’s importer. After that, you can use Transport to import from Yoast SEO.

Always make a backup before transporting! Before using Extension Manager’s Transport, I recommend deactivating the other SEO plugins so they won’t repopulate their data.

3. At “SEO Settings > Schema.org Settings > Connected Social Pages,” you can use any field to put any link you’d like. For a future major update, where I rework the settings page, I’m considering an automatically-iterating field so you can add thousands of links.

Still, I don’t think it helps to fill in those fields — no search engine actually acknowledges them. In a past update I hid those fields, but reintroduced them because people were left confused about where to put those links.

4. The optimized sitemap already doesn’t display archives. If you’re asking about the Core sitemaps (which activate when the optimized sitemap is disabled), then no, there’s no setting to hide taxonomy archives from those. You could use this filter to disable them:

add_filter(
	'wp_sitemaps_add_provider',
	fn( $provider, $name ) => in_array( $name, [ 'taxonomies', 'users' ], true )  ? null : $provider,
	10,
	2,
);

But I recommend using the optimized sitemap instead. Perhaps, for your use-case, we have historical sitemaps planned for large sites with millions of URLs, which will be part of a future major update.