Sybre Waaijer
Forum Replies Created
-
Hello!
Are you on WordPress 7.0? Is the site title “floating” off-center?
That’s a visual glitch introduced in WordPress 7.0. They still don’t have a useful API for editor styles—any update can shift plugin output without much consideration.
With WordPress 7.0, TSF’s colored checkboxes in the admin area are also rendering incorrectly. The accent colors for the 3-color theme are misplaced, and the unusual resizing of input fields caused layout shifts throughout the interface.
A fix already exists, but I was hesitant because WordPress Core was still making changes last week. I’ll get it out this week. Thank you for being with TSF for so long!
Hello!
I also received your emails (I noticed something went wrong with the form, but that’s not important now); I’m replying here so the answer is public too.
The SEO Framework doesn’t merge translated URLs into the default sitemap. The optimized sitemap is designed around language-specific sitemap endpoints: each sitemap should list URLs for the requested language, rather than mixing all translations into a single default-language sitemap. I detailed this here: https://github.com/sybrew/the-seo-framework/issues/69.
TranslatePress doesn’t store translated pages as separate WordPress posts/pages in the database. Instead, it translates the page output/string-by-string. Because TSF’s sitemap is generated from WordPress content records, we cannot yet reliably enumerate TranslatePress’s translated URLs for separate language-specific sitemap endpoints.
Not having URLs in the sitemap doesn’t prevent indexing of the (translated) pages, nor does it affect ranking.
TranslatePress outputs
hreflanglinks and translated permalinks directly on the pages. Google treats those page-levelhreflanglinks and (our dismissed) sitemaphreflangannotations as equivalent methods, allowing search engines to discover and index the translated versions through crawling.Still, I’m tracking improved support for the TranslatePress sitemap endpoint here: https://github.com/sybrew/the-seo-framework/issues/615.
This feature is currently proposed for the next TSF update. But I’ve fallen behind schedule, so it may move to the update after that.Hello!
Good to hear from you again — it has been a while. Thank you for sharing your honest take.
I get what you mean. Compared with some SEO plugins, TSF can look quiet, maybe even dull. That is intentional, but quiet should not feel abandoned.
About Twitter/X: you are right that “Twitter” feels outdated in everyday language. We already refer to the platform as X where that makes sense. The catch is technical:
Twitter Cardis still the name of the metadata protocol. That is not homage for Twitter; it is the protocol name. X, Discord, and LinkedIn still read meta tags such astwitter:card,twitter:title, andtwitter:image. Renaming the setting itself to X would make it less accurate and harder to recognize for people looking for the actual protocol. X also recently overhauled its developer documentation and removed many old references, which made this more confusing, so I wrote a clearer Twitter Cards and X sharing article about this.About Focus: I do not plan to move Focus into the free core plugin. Focus is a writing assistant, not basic SEO infrastructure. The free plugin already handles the SEO output itself — titles, descriptions, canonical URLs, robots directives, Open Graph, Twitter Cards, structured data, sitemaps, breadcrumbs, and many safeguards — without ads, tracking, branding, or nags. Focus is useful for people who want keyword and synonym guidance, but it is not required for correct SEO output. Paid extensions also fund the continued maintenance of the free plugin; I will not pretend otherwise.
On the dated feeling: some of that is WordPress. WordPress is simple and durable, but its admin UI is not modern, and WordPress 7.0 will, unfortunately, worsen that (in my opinion). TSF deliberately blends into WordPress rather than building a separate, flashier app-like interface around it. That may hurt us in screenshot comparisons. It also keeps TSF predictable, accessible, unbranded, and usable on professional sites where the dashboard should not become our sales funnel.
SEO itself also has not moved nearly as far as SEO plugin marketing pretends. Search engines still need the boring fundamentals done correctly: titles, descriptions, canonical URLs, robots directives, crawlable URLs, structured data, sitemaps, performance, and sane defaults. Many modern-looking plugin features are packaging: scores, dashboards, prompts, reports, alerts, and AI suggestions. Some may be useful, but many mostly look busy. TSF is built around what works, not what helps sell the upgrade. This also goes for AI (GEO/AIO) — the landscape hasn’t changed a bit.
That does not mean TSF is standing still. Our ww.wp.xz.cn plugin’s “last updated” date only changes when we publish a plugin release. Since 5.1.4, I have been working on 5.1.5 / 5.2.0. I also refreshed the website style (new buttons, sidebars, footer, etc.), and rebuilt the documentation and release notes. Last year, I built a state-of-the-art update service around Troy Client, so fixes can still be delivered reliably even if the Extension Manager itself has an issue.
Much of my best work is intentionally hard to see: security hardening, compatibility, safe defaults, reliable updates, privacy, accessibility, strict canonical handling, and safeguards against SEO attacks.
The WordPress plugin ecosystem, including SEO plugins, regularly experiences security issues. The SEO Framework still has none of that. It’s because I would rather spend engineering time preventing those than chasing a dashboard trend. That is not flashy, but it is the side I want TSF to be strongest on.
So yes, there is UI and workflow work I can improve. I won’t dismiss that. But TSF’s direction will remain users and professional sites first, sales second. If you have one or two concrete friction points from daily use, please share them. I cannot promise every feature will move into the free plugin, but I can take specific pain points seriously and improve the core where it makes sense.
Thank you again for sharing your thoughts. I hope this gives you a better idea of where I am coming from and where TSF is going. I am always open to feedback, and I want to make sure TSF continues to serve you well.
Hi Harald,
LinkedIn likely rejects your Open Graph image for two reasons:
1. Missing dimensions: The
og:image:widthandog:image:heighttags are missing. LinkedIn requires these to avoid downloading the image to calculate its size, which can cause LinkedIn to reject the image on failure.
2. Square ratio: The image is 1852×1752. LinkedIn expects a 1.91:1 landscape ratio (e.g., 1200×627).To fix these issues, use the Select Image button in the Social settings instead of a URL. Selecting from the Media Library lets you crop the image to the correct dimensions. It also ensures that the width and height tags are generated because TSF can store the image ID for image metadata retrieval.
To bypass LinkedIn’s cache during testing, append a query string like
https://example.com/?v=1in the Post Inspector.Forum: Plugins
In reply to: [The SEO Framework – Fast, Automated, Effortless.] Sitemap is lockedI’m glad you found the cause!
Some backstory: the sitemap sets a lock when it’s building a cached copy. This prevents it from becoming a denial-of-service attack vector. The lock is released once the sitemap is built, but it cannot be released if the process crashes. The lock is automatically released after 180 seconds or PHP’s max execution time (whichever is smaller).
In any case, if you don’t want the
landing_pagepost type to appear in the sitemap, don’t you also want it to be unindexable? It might then be easier to apply “noindex” to the post type; this will also remove the posts from the sitemap.Forum: Plugins
In reply to: [The SEO Framework – Fast, Automated, Effortless.] Multiple BreadcrumbHello!
Breadcrumbs are primarily navigation for visitors. They should show one clear path through the site, not every tag, category, or taxonomy relationship a post has. Tags, especially, are topic labels, not a hierarchy, so they usually make poor breadcrumb items.
TSF generates one breadcrumb trail. For posts with multiple hierarchical terms, you can set the primary term to reflect how visitors should understand and navigate the site. For custom post types, I recommend using the taxonomy hierarchy that reflects the actual site structure.
If this is only meant to influence search engines, I would avoid it. Search engines are best served by breadcrumbs that match useful, visible navigation. Adding extra breadcrumb paths just because the post has multiple tags or taxonomies can make the page less clear.
What problem are you trying to solve for visitors? If they need to discover related topics, visible tag/taxonomy links near the post content are usually more helpful than multiple breadcrumb trails. If you have a specific visitor-facing navigation layout in mind, please describe it, and I can point you toward the best option.
Forum: Plugins
In reply to: [The SEO Framework – Fast, Automated, Effortless.] Missing Field “image”Hello!
I looked at that page, and the image field is provided. Have you been able to address the issue since you opened this support topic? Or is another page affected than the one you posted? Thanks!
I tried to implement this in The SEO Framework. Upon testing, I ran into major issues with the current design of GeoDirectory’s compatibility layer. The way it currently works is fundamentally incompatible with third-party SEO plugins and breaks their expected behavior in a way that cannot be reliably worked around on our end. None of The SEO Framework’s data could load reliably on any GeoDirectory page without intricate and fragile workarounds.
GeoDirectory’s compatibility layer is doing far too much in a global
get_post_metadatahook, and it is now breaking third-party SEO plugins that rely on standard WordPress metadata APIs.The core problem is this: on GeoDirectory single pages, GeoDirectory compatibility code rewrites normal post metadata reads, causing them to return the details template page’s metadata instead of the actual listing’s metadata. This is not limited to layout metadata. It affects downstream plugin behavior because the rewrite occurs below the plugin layer, within a core metadata hook.
That is already bad enough, but the “preserve SEO metadata” logic is even worse:
1. It uses a local
$reserve_post_metaflag with hardcoded vendor checks.
2. There is no filter to declare “this is an SEO plugin whose metadata should be preserved”.
3. There is no generic compatibility contract for third parties.
4. Even the preservation path is inconsistent: the detection logic recognizes multiple SEO plugins, but the merge-back logic only restores Yoast and SEOPress-prefixed keys.This design makes core metadata semantics depend on which plugins and themes GeoDirectory happens to know about. That is not a compatibility layer. That is a global metadata router with vendor allowlists.
Why this is bad:
1. It breaks interoperability for any plugin that uses standard
get_post_meta()bulk reads or expected keyed reads.
2. It forces third parties into brittle plugin-specific workarounds instead of letting them rely on WordPress core behavior.
3. It makes compatibility effectively infeasible unless a plugin is explicitly vendor-whitelisted by GeoDirectory.
4. It creates silent failures. A plugin can appear to “work”, but custom metadata is ignored, and the plugin falls back to generated defaults.
5. It is not future-proof. Every new SEO or metadata-heavy plugin now depends on GeoDirectory maintainers knowing it exists and special-casing it correctly.Why a TSF compatibility layer is not really feasible until this is resolved:
1. The breakage happens below TSF, inside GeoDirectory’s interception of core metadata reads.
2. TSF cannot reliably distinguish “template inheritance” from “metadata corruption” after the read has already been rewritten.
3. Any workaround on our side becomes a patch over undefined behavior, not a real compatibility layer.
4. As long as GeoDirectory conditionally rewrites core metadata based on hardcoded plugin/theme checks, third-party compatibility will always be partial and fragile.Actionable steps:
1. Stop rewriting bulk post-meta reads for third-party plugin data on GD single pages.
2. Restrict template-page metadata inheritance to explicit layout/template keys only, not arbitrary plugin metadata.
3. Add a filter around the “preserve third-party SEO metadata” decision so unknown plugins can opt in without being hardcoded.
4. Add a filter for declaring preserved meta prefixes or explicit meta keys.
5. Add a filter or opt-out around theget_post_metadataoverride itself so third parties can bypass it during their own reads.
6. Remove vendor-specific assumptions from this path wherever possible.
7. Add tests for an unknown third-party plugin that uses standard WordPress metadata reads, both bulk and keyed.
8. Document exactly which metadata paths GeoDirectory rewrites and under what conditions.Until this is fixed, third-party SEO compatibility will remain unreliable by design. I will keep it at the snippet plugin for now and park my planned integration of TSF’s SEO variable system until this is resolved.
I’m not willing to ship code that’s half-broken by design and creates silent failures for unsuspecting users. I hope GeoDirectory can address this soon so we can move forward with a real compatibility layer instead of a patchwork of vendor-specific hacks.
If you could reopen the GitHub repo, I can provide quick and actionable feedback on any proposed changes to address this.
Hi efa!
The Local extension outputs LocalBusiness structured data, which requires a physical address by spec — it is not the right fit for a service-area business that operates from a home office without a public-facing location.
For your situation, Google Business Profile is the better tool. It is specifically designed to handle service-area businesses and lets you:
1. Set up your profile as a “service-area business” so your address is hidden from the public.
2. Define the areas you serve (cities, postal codes, regions) instead of showing a street address.
3. Turn off “Show business address to customers” in your profile settings.Google’s own instructions for this:
– Manage your service areas: https://support.google.com/business/answer/9157481
– Hide your address (see “Remove your address”): https://support.google.com/business/answer/2853879Google Business Profile also populates the knowledge panel and Maps results for local searches, which is where the real local SEO impact comes from. The structured data from the Local extension supplements that, but does not replace it — and without a public address, LocalBusiness structured data is incomplete by definition.
The image URL field in the Local extension settings is optional, so that part is not a blocker. But the address requirement reflects the schema.org spec itself, not something we can work around.
Forum: Plugins
In reply to: [The SEO Framework – Fast, Automated, Effortless.] Quick edit and bulk editHi Ralf!
Quick edit is available — when you hover over a post or page in the list table and click “Quick Edit”, you will see fields for Meta Title, Meta Description, Canonical URL, Redirect URL, robots settings, and Article Type (via Articles extension). These work per individual post, including with WPML translations (each translation is its own post).
Bulk edit for titles and descriptions, however, is intentionally not supported. We only offer bulk editing for robots’ settings (indexing, link following, archiving) and Article Type. The reason is that Google explicitly recommends unique descriptions for every page:
Identical or similar descriptions on every page of a site aren’t helpful when individual pages appear in search results. Wherever possible, create descriptions that accurately describe the specific page. — Google Search Central
The same principle applies to titles. Google will actively override duplicate titles with its own generated versions:
Here are the most common issues we see with title links in search results […]: Micro-boilerplate text in <title> elements — When there are repeated boilerplate text in <title> elements for a subset of pages within a site. — Google Search Central
A bulk edit field for titles and descriptions would primarily enable setting the same (or very similar) text across many pages at once, which runs counter to what search engines expect. My design philosophy with quick edit — one post at a time — naturally encourages unique content for each page.
For your three-language WPML setup, quick edit should work well: each language version is a separate post in the list, so you can inline-edit them individually right from the post list.
- This reply was modified 1 month, 2 weeks ago by Sybre Waaijer. Reason: typo
Forum: Plugins
In reply to: [The SEO Framework – Fast, Automated, Effortless.] Meta descriptionsHello!
I wrote a detailed article on exactly how this works here: https://kb.theseoframework.com/kb/explaining-the-description-generator/.
The getter-phase notes that it strips: sole link paragraphs, all shortcodes, and all headers, images, scripts, lists, forms, etc. It also removes all leftover HTML.
It only gets from the Post excerpt or content fields. If the excerpt is filled, it will only use that.
Hi there!
Those tables are completely inert once Rank Math is deactivated. Nothing queries them, so they do not affect your site’s performance or caching — they just take up a bit of disk space.
There is no urgency to remove them, but if you prefer a clean database, you can safely drop them all. TSF does not use any of them:
–
wp_rank_math_404_logs
–wp_rank_math_analytics_gsc
–wp_rank_math_analytics_inspections
–wp_rank_math_analytics_objects
–wp_rank_math_internal_links
–wp_rank_math_internal_meta
–wp_rank_math_redirections
–wp_rank_math_redirections_cache(Replace the
wp_prefix with your actual table prefix if you changed it.)You can drop all eight via phpMyAdmin or any database management tool. If you already ran Transport (our migration extension), your SEO data has been migrated into TSF’s own storage, and the original Rank Math entries in the common tables (postmeta, termmeta) were cleaned up as part of that process.
Regarding the
wp_actionscheduler_*tables — those are NOT from Rank Math. They belong to the Action Scheduler library, which is shared by multiple plugins. WooCommerce is the most common plugin that uses it, but other plugins may rely on it as well. Deleting those tables could break functionality in any plugin that depends on Action Scheduler.If you want to check whether anything besides Rank Math is still using them, open phpMyAdmin, go to the
wp_actionscheduler_actionstable, and search the “hook” column with a NOT LIKE filter for%rank_math%. If that returns no rows, nothing else is using it. But if it returns rows, other plugins depend on those tables, so you should leave them alone.Either way, Action Scheduler automatically cleans up completed and canceled entries after about 31 days. So any leftover Rank Math rows in those tables will purge themselves over time as long as another plugin (like WooCommerce) is still active and loading Action Scheduler.
In short: you can drop the eight
rank_mathtables freely, but keep theactionschedulertables unless you are certain no other plugin depends on them.Thank you for giving The SEO Framework a try!
Variable/dynamic placeholders in meta titles are not yet natively available in TSF. I have been tracking this as a feature request since 2017, but demand has stayed substantially low, so it has not been prioritized. Most of the underlying automation is already written — all the transformation groundwork has even been done in Transport –, though, so it will land eventually.
In the meantime, you can achieve exactly what you described with a small code snippet using the the_seo_framework_title_from_generation filter. It lets you modify the auto-generated title per post, so for your “Service Areas” post type, you could prepend “Homes for Sale in ” to whatever the post title is.
If you or a developer on your team would like the snippet, let me know, and I will follow up with it. All I need is the post type name of “Service Areas” (that’s a label, not a name).
Forum: Plugins
In reply to: [The SEO Framework – Fast, Automated, Effortless.] AI Search FeaturesHi Greg,
I see you also opened an issue on GitHub about this. Let’s continue there: https://github.com/sybrew/the-seo-framework/issues/755.
Forum: Plugins
In reply to: [The SEO Framework – Fast, Automated, Effortless.] Sitemap Robots.txt BugHello!
Thank you for reporting this issue! I can confirm that this is a bug (regression), and it will be fixed in version 5.1.5 (or 5.2).
In this commit, when I overhauled the robots.txt output for TSF v5.1, I made an error in extracting the WordPress Core sitemap URL. We grabbed the sitemap URL from WordPress, but cleaned it up incorrectly, so it was silently discarded every time. This issue has been fixed for the next release.
5.1.5 (or 5.2) will be shipped close to WP 7.0’s release.