Sybre Waaijer

Hi Harald,

LinkedIn likely rejects your Open Graph image for two reasons:

1. Missing dimensions: The og:image:width and og:image:height tags 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=1 in the Post Inspector.

Hello!

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.

Hi 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 3 weeks ago by Sybre Waaijer. Reason: typo

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_actions table, 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_math tables freely, but keep the actionscheduler tables unless you are certain no other plugin depends on them.

Hi 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.

Hello!

Transport transforms and migrates metadata; it doesn’t copy it. So, after transporting, the old data is replaced — in other words, yes, the original Rank Math metadata is lost. Transport also cleans up much of the junk that Rank Math leaves behind, so your database will be much cleaner after the import.

TSF stores its post metadata in the same _genesis_* fields that Genesis uses — it was originally an extension of the Genesis Framework. This means that if you deactivate TSF after importing, Genesis will still read the imported post metadata (title, description, canonical URL, robots).

That said, I recommend against relying on Genesis for SEO. SEO is out of scope for a theme — it should do theme stuff. We actually use the Genesis Framework for our own website, and TSF was born from it (originally, it just filled in Genesis’s description fields, hence the plugin slug “autodescription”). When TSF is active, it disables Genesis’s SEO output and puts a robustly refined SEO powerhouse in its place. Since Genesis inspired our design philosophy, you’ll feel right at home — but with structured data, social meta, advanced robots, sitemaps, advanced query protection, and much more at your disposal.

Hi @adam426,

Please open a new topic, I’d love to help you there!