Three Google Search Console warnings arrived across three WordPress websites. Each warning pointed to a different technical SEO problem: missing images returning 404 errors, obsolete product URLs appearing in a sitemap, and canonical tags that did not match the public page URLs.
OpenClaw handled the technical investigation, applied narrowly targeted corrections, and verified the public results. The work is a practical example of how an AI agent can support a web team without making uncontrolled changes.
Issue 1: missing media files caused 404 errors
On biohealth.ca, four missing media references affected six published posts. Broken image references are more than a visual nuisance: they create failed requests, weaken page quality, and can continue appearing in search reports long after an editor forgets about them.
The missing references were replaced with valid, relevant images already available in the media library. Verification then confirmed that the old references were absent from the sitemap and that all four replacements returned HTTP 200.
Issue 2: obsolete product records polluted the sitemap
WordPress911.ca had 15 obsolete SureCart product records in the source set: nine dead URLs and six legacy or redirected records. Search engines should not be encouraged to crawl URLs that are no longer valid or useful.
The obsolete records were set to noindex and excluded from the sitemap using the site’s existing SureRank configuration. A follow-up check found zero obsolete product URLs in the sitemap. The four current products remained present and all returned HTTP 200.
Issue 3: canonical URLs pointed to WordPress query links
On oshawachiropractor.com, nine published posts had explicit canonical URLs in the old ?p=ID format instead of their public permalinks. That can send conflicting signals to Google and contribute to “Duplicate, Google chose different canonical” reports.
Each canonical was corrected to match its public permalink. All nine pages were then checked publicly: every page returned HTTP 200 and self-canonicalized to the correct URL.
What made this safe automation
- Only the records connected to the reported problems were changed.
- Rollback files were created before any production edits.
- Public HTTP responses, sitemap contents, and canonical tags were verified after the work.
- Caches were flushed so the verified result matched what visitors and crawlers could see.
- No plugins were installed and no unrelated content was changed.
The important lesson is simple: useful AI automation does not stop after changing a database value. It closes the loop by preserving rollback options, checking the public result, and leaving human approval where it belongs.
If you need help investigating a WordPress or search visibility problem, explore our OpenClaw services or contact the OpenClaw911 team.
