Search engines

This is where the title and meta description a page serves are decided. Three sources, in a fixed order: the value typed on the page itself wins, then the template for that post type, then nothing at all.

Templates take %%variables%% that resolve per page. You do not have to imagine the result — the "Reads as" line under each field renders the template against a real post from this site.

Nothing is written to your posts. The values are stored as this plugin's own fields and served through WordPress hooks at render time, so turning the module off returns the page to exactly what it emitted before.

With another SEO plugin active and no takeover enabled, this tier emits nothing. One title source at a time is the rule, and two plugins writing one tag is the bug it exists to prevent.

A social card falls through three sources in order: the override on the post, then the post's featured image, then the site default set on this screen.

The X card has fields of its own, and an empty one is not an empty card — it falls back to the Open Graph values. That is what most pages want, and the editor says so beside the field rather than leaving you to test it.

The preview in the post editor shows the value that would actually be served for that post, resolved through the same fallback chain. It is a preview of the output, not a mock-up of a network.

Everything this plugin says about a page leaves in one JSON-LD block: the site and its owner, the breadcrumb trail, whatever you built on the post itself, and any template whose conditions match. One block, one graph — a page carrying two competing graphs is worse off than a page carrying none.

A node missing something its type requires is dropped whole rather than emitted half-built, and the editor names the property that was missing. Nothing is invented on your behalf: no ratings, no reviews, no duration for a file nobody opened.

Structured data makes a page eligible for a rich result. Whether an engine draws one is the engine's decision, and no screen in this plugin will tell you otherwise.

If another SEO plugin owns the JSON-LD on this site, ours stays silent until you take that over on the Compatibility panel.

Breadcrumbs render only where you put the shortcode or the template tag. They are never injected into a theme uninvited, which is why there is no "enable breadcrumbs" switch that silently changes how every page looks.

The BreadcrumbList schema rides along automatically with the visible trail. Place one and you get both; place neither and neither is emitted.

When a published page's URL changes, the old address answers with a 301 to the new one. The rule is recorded the moment the permalink moves, so the link somebody bookmarked last year keeps working.

The rule table is kept loop-free: a set of rules that points at itself is refused rather than saved, because a redirect loop takes a page off the internet more thoroughly than a 404 does.

Every rule can be removed, and removing one stops that redirect immediately. Nothing is written to .htaccess for this — the rules live as plugin data and are served by WordPress.

A wrong hreflang tells every engine that the wrong page is the translation, and the damage outlasts the fix. So this screen refuses rather than guesses, and it says which refusal you are in.

There are four. Another SEO plugin is active, so it owns hreflang and we emit nothing. No multilingual plugin is installed, so there is no translation set to describe — a /de/ in a URL is not evidence that a page is German. WPML or Polylang is here but the takeover is off, so they emit theirs and ours would be a second set on the same page. Or the takeover is on, in which case theirs is suppressed through their own documented filter and ours is emitted.

This has nothing to do with the plugin's own interface being translated. That is a separate thing that shares a word with it.

Alt text and image titles can be filled from patterns built out of real data this site holds: the file name, the post title, the site title. Nothing here looks at the picture, so nothing here will claim to describe what is in it.

The upload automation is off by default and its patterns start empty. Switched on, it fills only fields that are empty. Overwriting words an author wrote is not automation, it is data loss on a schedule.

Find-and-replace across the library previews before it writes, snapshots each item's prior value, works in capped batches, and reports per item. Run the same replacement twice and the second run changes nothing and says so.

Restore compares before it restores. An image whose alt text you edited by hand after the batch is skipped and reported, never clobbered.

Images are re-encoded on this server, through the image library WordPress already uses. No image leaves the site, there is no API key and there is no bill.

Your uploaded original is copied to a sidecar file, verified by size and checksum, before the full-size file is touched. If that copy cannot be made, the optimization does not happen. An existing sidecar is never overwritten.

The preview says estimated, because bytes are not knowable before encoding. The receipt says measured, because by then they are. An encode that came out larger than the original is refused and the original is left exactly as it was.

The sidecar survives uninstalling the plugin, deliberately. Removing our records must not destroy the way back to your original file for an image still sitting in an optimized state.