The U&AI content platform audits client sites and produces a list of SEO issues. This plugin is how those fixes reach your site — and, just as importantly, how you see and control them.
It never renders anything over your own content. If a fix cannot be made to the real value, it is not made: the platform raises it for a person instead. Concretely:
robots directives are merged: the plugin may add noindex, and can never remove or override one you set.On every post, page, category and tag there is a “U&AI SEO” panel listing everything the plugin renders for that item: 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 yours permanently. The field is marked as owner-edited and no automated write can overwrite it afterwards — enforced inside the plugin at the metadata layer, so it holds for every write path, not only the ones that ask nicely.
Tools U&AI SEO covers the site-wide behaviour: every redirect rule with a delete button, plus 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.
When another SEO plugin owns the <head>, the bridge does not compete for it.
With Yoast SEO, values are written into Yoast’s own fields, so they appear in Yoast’s sidebar where you already edit, and they stay there if you deactivate this plugin. A value you type in Yoast always wins: the 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. The same applies to a per-post noindex you set in Yoast — a value from the platform can never re-expose a page you hid.
With other SEO plugins the platform writes their fields over the WordPress REST API where they expose them, and reports the fix as needing manual attention where they do not.
The SEO title and meta description are also registered with show_in_rest, so they can be written in the same POST /wp-json/wp/v2/posts call that creates a post:
{"title": "...", "content": "...", "meta": {"_uandai_seo_enabled": true, "_uandai_seo_title": "...", "_uandai_meta_description": "..."}}
This is what lets U&AI publish a generated article — body, featured image and SEO fields — in one request. The keys are protected meta, so writes require the edit_post capability for the target post, and they are subject to the same owner-edit protection as everything else. Canonical URL and robots stay bridge-only because their validation depends on the target post.
Post types are every public REST-enabled type (always including post and page); filter with uandai_seo_bridge_rest_meta_post_types.
If the bridge detects an active SEO plugin (Yoast, Rank Math, AIOSEO, SEOPress, Squirrly, The SEO Framework, or any plugin whose folder name contains “seo”), head_injection_safe becomes false in /health and the plugin stops emitting its own head tags, so there are never duplicate <title>, <meta> or <link rel="canonical"> tags.
To force the bridge to coexist with another plugin, hook uandai_seo_bridge_allowed_seo_plugins (returns an allow-list of plugin slugs) or uandai_seo_bridge_head_injection_safe (returns the final boolean).
By default the bridge rejects canonical URLs whose host differs from the post’s host. Pass force_external_canonical=1 (in the request body or query string) to permit cross-host canonical values when migrating between domains.
All endpoints live under /wp-json/uandai-seo/v1/ and accept and return JSON. Authenticate with the same WordPress Application Password the U&AI dashboard already uses. Site-wide settings and /health require manage_options; per-object routes require edit_post or edit_term on that specific object.
Per post and term:
GET|POST /page-meta/{post_id} — read or write a post’s SEO fieldsPOST /page-meta/{post_id}/clear — remove what the plugin manages (values you set by hand are preserved)GET|POST /term-meta/{taxonomy}/{term_id} — the same for a category or tagPOST /term-meta/{taxonomy}/{term_id}/clearPOST /image-alt/{post_id} — fill empty image alt textSite-wide:
GET /health — version, capabilities, detected SEO plugins, duplicate installs, and which features you have switched offPOST /resolve-url — map a crawled URL to a post or termGET|POST /redirects — list or replace redirect rulesGET /robots, POST /robots/configure — robots.txt additionsGET /security-headers, POST /security-headers/configureGET /dom-normalize, POST /dom-normalize/configure — the body passes (image alts, external-link rel)POST /sitemap/configurePOST /snippet-config — analytics snippet configurationPOST /purge-cache — best-effort cache purge after a writeThis plugin connects your site to U&AI (https://uandai.co), the platform that produces the SEO fixes it writes. A U&AI account is required to use it: you create a WordPress Application Password and enter it in the U&AI dashboard, and that is what authorises everything below.
The plugin’s own PHP never makes an outbound request. Traffic between your site and U&AI happens in two ways.
1. U&AI calls your site. The platform authenticates against the uandai-seo/v1 REST namespace with the Application Password you supplied and writes the SEO fields listed under “Endpoints”. Nothing leaves your server except the responses to those calls.
2. The analytics snippet runs in your visitors’ browsers. Only if you enable the U&AI analytics snippet for this site in the U&AI dashboard: the platform pushes a script URL to POST /uandai-seo/v1/snippet-config, and the plugin then enqueues that script on the front end. The script is served by your U&AI instance — by default https://app.uandai.co/static/platform/snippet.js — reads its collection settings from https://app.uandai.co/api/platform/snippet-config/, and reports to https://app.uandai.co/api/platform/events/.
What the snippet sends, by the collection level configured on your U&AI account:
_ga and _fbp).The snippet is never loaded in wp-admin and never for a logged-in WordPress user, so staff activity stays out of your visitor numbers.
Consent: whether the snippet waits for consent is a per-account setting in U&AI. With it on, nothing but a page view is recorded until your consent tool calls window.__uandaiOnConsent() — form interaction, session recording, third-party cookie values and the GA4 identify call all stay off until then. With it off, collection starts on page load. Set it to match the consent regime your site operates under.
To stop it: switch the snippet off for the site in the U&AI dashboard (the platform then pushes enabled: false), or deactivate this plugin — deactivating removes the snippet and ends the platform’s ability to write to the site.
U&AI terms of use: https://uandai.co/terms
U&AI privacy policy: https://uandai.co/privacy