U&AI SEO Bridge

Changelog

0.15.0

• This plugin no longer renders anything over your own content. Earlier versions replaced the first <h1> on a page and prepended their own, on every render, after your page builder had finished. Nothing here reacted to a human edit, so an owner who changed the heading in Elementor was silently overridden every time — one site could not edit a heading at all until they deactivated the plugin. Headings are now changed in the page’s own stored content (Elementor’s data or the post content), so the edit is visible and reversible in your own editor. A page this plugin cannot edit raises a task for a person instead of a render-time override.
• A “U&AI SEO” panel on every post, page, category and tag. Everything this plugin renders for that item is now shown where you edit it: search title, meta description, canonical, noindex/nofollow, structured data, language alternates, pagination links, injected image alt text, and whether the plugin is managing that item at all. Text fields are editable; machine-generated additions have a “Remove it” checkbox. Anything you set by hand is marked as yours, and no automated write can overwrite it afterwards — enforced inside the plugin, so an older backend cannot bypass it.
• Tools → U&AI SEO lists the site-wide behaviour: redirect rules (with a delete button per rule) and switches for image-alt injection, external-link rel attributes, HTTP security headers and the analytics snippet. A switch you turn off stays off — no automated request can turn it back on.
• With Yoast SEO active, values are written into Yoast’s own fields instead of being rendered over them, so they appear in Yoast’s sidebar where you already edit. A value you type in Yoast always wins: this plugin only fills a field you left empty, and it records what it wrote so it can update its own value later without ever touching yours.
• Third-party JSON-LD is no longer deleted. Earlier versions removed any ld+json block they judged invalid — schema your own plugins emitted, removed at render time with no trace. Invalid schema is still reported as an issue; deciding what to do about it is yours.
• Redirect rules now only fire on an address that genuinely 404s. If you republish a page at a path that had a redirect rule, visitors reach your page again instead of being sent away from it.
• On a page where your theme or another SEO plugin already prints a meta description, this plugin’s own tag stands down rather than deleting theirs.
• robots directives are merged rather than replaced: this plugin may add noindex, and can never remove or override one you set.
• Image alt text is only ever added where alt is empty, and where an image is in the Media Library its own alt text is what renders — clear it there and nothing is injected.
• Fixes: duplicate <title> tags are now actually de-duplicated (the old routine removed nothing and logged PHP notices); injected alt text can no longer produce malformed <img> markup; the forced content-type header uses the site’s configured charset instead of assuming UTF-8; text inside <script>, <template>, <textarea> and HTML comments is left alone by all content passes.

0.14.0

• Archive URLs resolve on sites whose permalink structure starts with a fixed segment. 0.12.2 matched a taxonomy’s own rewrite slug, but WordPress prepends the permalink FRONT to it: a site using /article/%postname%/ has the front /article/, its category taxonomy still reports its slug as plain category, and the real archive lives at /article/category/<term>. Matching the slug alone found nothing on exactly the sites the fix was written for — one production site had every archive come back unresolved even after upgrading. The front-prefixed form is now tried first, the bare slug second, and the resolved term’s own permalink still has to equal the requested path before it is returned, so neither form can send a fix to the wrong archive.
• Date archives (/2026/, /2026/04/, /2026/04/15/, with or without a permalink front) now report date_archive_unsupported instead of a bare unresolved. WordPress builds them from a template, so there is no post or term for this plugin to write to and no re-scan will produce one. Saying so stops them being retried run after run — and stops meta descriptions being generated for pages that can never receive them.

0.13.0

• The analytics snippet is now added with wp_enqueue_script() instead of being printed straight into <head>. WordPress had no record that the tag existed, so caching, script-optimisation and consent plugins could reorder or defer everything around it without accounting for it. It still loads early in <head> and still carries data-site-id on the tag, which the snippet reads as it boots.
• Read permissions now match what is being read. Site-wide settings — robots rules, security headers, DOM normalisation, snippet config — and /health require manage_options, as the matching write routes always did; previously any user who could draft a post could read them, and /health also lists the site’s active SEO plugins. Reading a single post’s or term’s SEO metadata now requires edit_post / edit_term on that specific object instead of a blanket edit_posts, which had allowed walking post ids to read the SEO fields of other people’s drafts. If the Application Password configured in U&AI belongs to a non-administrator, /health now returns 403 and the bridge will not be used — it belonged to an administrator already for any site where writes worked.
• The DOM normalisation output buffer is now explicitly closed at shutdown rather than left for PHP to flush at the end of the request, and on WordPress 6.9+ the plugin joins core’s own template output buffer instead of opening a second one. Two buffers opened by two components can be closed in the wrong order, which puts one component’s output inside the other’s.
• Added an “External services” section documenting exactly what this plugin connects to: the U&AI REST calls into your site, and — when you enable it — what the analytics snippet sends from your visitors’ browsers, field by field, with the consent switch and the terms and privacy policy links. Nothing about the behaviour changed; it was simply never written down.
• Removed a developer-only test checklist from the plugin package.
• Passes WordPress’s own Plugin Check with no errors and no warnings, and is tested against WordPress 7.1.

0.12.2

• POST /resolve-url now resolves archive URLs for ANY registered public taxonomy, at any depth in the path. It previously only recognised category or tag sitting at the very first path segment, so a site that gives its custom post type a permalink base — /article/category/blog — or uses a custom taxonomy — /article/case-study-category/investing — had every archive URL come back unresolved. Those URLs then fell through to a post lookup, which cannot resolve an archive because an archive is not a post. On one production site this single gap accounted for 77% of a remediation run: titles, meta descriptions, H1s and canonicals all computed, then discarded for want of a term id.
• Matching is against each taxonomy’s real rewrite base, longest first, and the resolved term’s own permalink must equal the requested path before it is returned — so two taxonomies sharing a term slug (/article/case-study-category/strategy and /article/portfolio-category/strategy) resolve to their own terms and a fix cannot land on the wrong archive.
• Author archives now report reason: author_archive_unsupported instead of a bare unresolved. There is no post or term behind one for our meta to attach to, and saying so keeps genuinely fixable URLs from being buried alongside them.

0.12.1

• POST /resolve-url now resolves URLs it previously refused. url_to_postid() matches against the site’s canonical home URL and rewrite rules, so it returned “not found” for URLs that are plainly this site’s: a www. host where WordPress is configured without it (or the reverse), an http:// URL on an https site, a trailing slash that disagrees with the permalink structure, and custom post types whose permalink base does not round-trip. Each of those made an applicable SEO fix unresolvable — the fix was right, we just could not name the post to write to.
• The fallbacks stay exact rather than fuzzy: the host is only ever swapped for this site’s own www/non-www twin, so a foreign URL that happens to share a path still does not resolve; and the custom-post-type slug lookup is limited to public REST-enabled types and refuses when two posts share the slug, because then the path does not identify either of them.

0.12.0

• Installing the plugin now installs the U&AI analytics snippet too. Previously someone had to paste a script tag into the theme by hand, so most sites never did it and reported no visitor data at all. The platform pushes the site id to POST /uandai-seo/v1/snippet-config and the plugin renders the loader in <head> — no theme editing, and no chance of pasting the wrong site id.
• The snippet is not rendered in wp-admin or for logged-in users, so staff traffic stays out of the client’s page-view counts. What the snippet may collect is still decided server-side and fetched at runtime, so a site cannot opt itself into heavier collection.
• /health reports snippet_installed and the snippet_install capability.

0.11.3

• Every write the bridge exposes is now safe to retry. Send an Idempotency-Key header and a replay of that key returns the STORED response instead of performing the write a second time — so a request that times out AFTER WordPress applied it no longer forces a choice between duplicating the change and skipping it. Applied at the REST dispatch layer, so it covers every write route, including ones added later.
• /health gains a capabilities array describing what the bridge can DO (as opposed to supports, which lists the meta fields it can write), so a backend can detect idempotency support without matching on version numbers.
• Keys are kept for 7 days and swept by a daily cron event; a request still in flight answers 409 with Retry-After, and reusing a key with a different body is rejected rather than served the wrong result.

0.11.2

• A second copy of the plugin is now inert instead of fatal. WordPress installs a zip as a NEW plugin when its folder differs from the installed one, and both copies then load — the second inherited the first’s paths, never declared its own classes, and fataled the moment it called one. First copy to load now wins; any other returns immediately.
• /health reports the plugin’s actual install path and any duplicate copies, so this is diagnosable without shell access.

0.11.1

• Fixes a fatal error on activation. 0.11.0 inspected the site while registering — it called the conflict detector and pulled in wp-admin/includes/plugin.php at plugins_loaded, far earlier than any of that code had run before. Registration now adds its filters and inspects nothing; every check happens inside the callbacks, which run at wp_head with the full API available. Yoast detection no longer needs an admin include at all.

0.11.0

• Yoast passthrough now covers robots directives and JSON-LD as well as title, description and canonical.
• Schema is MERGED into Yoast’s @graph rather than emitted as a second graph: a type Yoast does not output is appended, a type it does output keeps Yoast’s node and only gains properties Yoast is missing. Yoast’s values always win, so its internal @id references stay intact.
• The passthrough no longer registers when the bridge itself is rendering the head (an allow-listed SEO plugin), which would have produced our values twice.
• /health advertises yoast_passthrough_robots and yoast_passthrough_schema separately, so the platform never routes a fix to a version that cannot render it.

0.10.0

• Coexists with Yoast SEO instead of standing down: when Yoast is active the bridge feeds its stored SEO title, meta description and canonical through Yoast’s own wpseo_title / wpseo_metadesc / wpseo_canonical filters. Yoast still renders the head — it renders your values. Nothing to disable, no duplicate tags, and deactivating this plugin restores Yoast’s own values exactly.
• Heading fixes (H1/first H2) no longer stand down for a resident SEO plugin. Those are body content; no SEO plugin writes them.
• /health advertises yoast_passthrough so the platform can route meta fixes to sites where Yoast owns the head.

0.9.0

• SEO title and meta description are writable through the core REST API (meta on /wp/v2/posts), so a published article carries its SEO fields in the create call.
• /health advertises core_rest_meta plus the registered meta keys.
• Sitemap, pagination links and JSON-LD output hardened per WordPress Plugin Check; redirects now use wp_safe_redirect() with an allow-list built from the configured rules.

0.1.0

• Initial release: REST namespace, head renderer for title/meta/canonical/robots/JSON-LD, conflict detection.