Verified the live WordPress sitemap configuration for aguiarinjurylawyers.com. Rank Math is active and serving the canonical sitemap index at https://aguiarinjurylawyers.com/sitemap_index.xml. The production MU guardrail file is present at /var/www/html/public_html/wp-content/mu-plugins/seo-sitemap-authority.php. The real Kadence setting, kadence_theme_options['disable_sitemap'], is truthy, and WordPress core sitemap output verifies as disabled via wp_sitemaps_enabled=false.
Public QA after cache cleanup: /sitemap_index.xml, /post-sitemap.xml, /page-sitemap.xml, /category-sitemap.xml, and /video-sitemap.xml returned 200 across repeated checks. /wp-sitemap.xml and /sitemap.xml returned 301 to the canonical Rank Math sitemap index. robots.txt contains exactly one Sitemap: directive, pointing to https://aguiarinjurylawyers.com/sitemap_index.xml.
I made and rolled back one attempted PHP-level fix for /?sitemap=1. It was safely reverted because WordPress/Rank Math maps pretty sitemap URLs into the same internal query variable, so a MU-plugin load-time redirect can accidentally redirect canonical sitemap files too. The temporary file seo-sitemap-query-redirect.php is absent locally and on production. Remote rollback backups exist at /var/www/html/public_html/wp-content/mu-plugins/seo-sitemap-authority.php.bak-20260512-132512 and /var/www/html/public_html/wp-content/mu-plugins/seo-sitemap-authority.php.bak-robots-20260512-1723.
I flushed WordPress object cache, rewrite rules, WP Rocket domain cache, and purged Cloudways Varnish through the documented Cloudways API OAuth plus /service/varnish flow. This corrected intermittent stale self-redirects that appeared after the reverted experiment.
Google Search Console sitemap resubmission did not complete. Both local service-account keys, GSC_SERVICE_ACCOUNT_JSON and GSC_OWNER_SERVICE_ACCOUNT_JSON, now fail token minting with invalid_grant: account not found. The Google Ads OAuth refresh-token lane also fails with deleted_client, so it cannot be used as a Search Console fallback.
Bing Webmaster Tools submission did not complete. BING_WEBMASTER_API_KEY is still missing from the vault. Also, Bingbot currently receives Cloudflare 403 for the canonical sitemap while Googlebot receives 200, so Bing submission would be less useful until bot access is fixed.
The direct query endpoint /?sitemap=1 still returns Rank Math XML with 200. It is not advertised in robots.txt, and the normal alternate pretty endpoints redirect correctly. A server-level Nginx/Cloudways rule would be safer than a PHP-level rule if this endpoint must be forcibly redirected.
The live WordPress sitemap authority state is verified and cache-stable. The remaining items are access/configuration blockers outside the current safe PHP/WordPress scope: Search Console credentials, Bing WMT API key, and Bingbot Cloudflare access.
A capable next agent can start by repairing the GSC service account or creating a fresh mutation identity, then granting it Search Console property access before retrying sitemaps.submit for sc-domain:aguiarinjurylawyers.com. For Bing, add a real Bing Webmaster Tools API key to the vault and Notion secret record, then retry after Cloudways/Cloudflare allows Bingbot. If /?sitemap=1 appears in a crawl, prefer a server-level redirect rule that checks the literal original request URI before WordPress rewrites, rather than a MU-plugin redirect.
Use CLI/API first. Load /Users/samaguiar/Documents/Projects/.credentials/vault.env. WordPress production SSH uses SSH_HOST, SSH_USER, SSH_PORT, and SSH_PASS. The Cloudways API cache purge path was successful with /oauth/access_token followed by /service/varnish using server_id=1615235 and action=purge. Avoid reintroducing seo-sitemap-query-redirect.php; it was removed because it can catch canonical sitemap rewrites. QA options were mirrored to /Users/samaguiar/Documents/Codex/_qa-queue/2026-05-12.md.