U&AI SEO Bridge

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.