python Case study

WordPress SEO Doctor Bot

Assessing a WordPress site normally means installing a plugin on it, which is exactly what the owner of a production store does not want. This connects over the REST API with a credential the owner creates and can revoke, and reads the site from outside.

Back to projects All case studies SEO AI showcase

The business problem

Site audits are either generic checklists that ignore what is actually installed, or plugins that add code to the production site being audited. Neither is acceptable on a live commerce store: the first produces advice that does not apply, and the second adds surface area to the system whose stability is the reason you are auditing it.

What I delivered

A FastAPI service exposing both a browser interface and a callable API over the same core.
A WordPress connector authenticating with an application password over the REST API, requiring nothing to be installed on the target.
Configuration separated from logic, holding the endpoint, credentials and engine selection independently of the analysis.
A dedicated connector error type, so an unreachable site, a permission problem or an unexpected response shape reads as an infrastructure failure rather than as an audit finding.
Model selection as configuration, so the reasoning engine can change without touching the diagnostic code.
CORS configured so a separate front end can be added later without restructuring the service.

Technical approach

Application passwords rather than a plugin or a key of mine. The owner issues it, sees it listed against their user, and revokes it themselves when they are done.
The connector is isolated behind its own module and error type because most real failures here are transport and permission problems, and reporting those as findings would be actively misleading.
Credentials live in the configuration layer and never in the analysis path, so there is no route by which they end up in a report.
One core behind two interfaces, so anything the browser view can show is also available programmatically.

Result and evidence

A live WordPress or WooCommerce install can be assessed without installing anything on it, and the findings refer to what that site actually has. Access is granted and revoked by the site owner.

Commercial value

For anyone maintaining several stores, the property that matters is that assessment adds nothing to production. Revocable read access and no additional plugin surface.

implementation-brief.readme

Readable implementation brief

implementation_brief {
  project: "WordPress SEO Doctor Bot"
  stack: "Python, FastAPI, Jinja2, Pydantic"
  access: "WP REST API + application password, owner-revocable"
  install_on_target: "nothing"
  layout: "core/wp_connector + core/config, isolated"
  errors: "dedicated connector error type; transport and
           permission failures never read as findings"
  engine: "selectable via config, not hardcoded"
  surfaces: "browser UI and API over one core"
}

What this project shows

The trust model is the design. Asking an owner to install my code on their production store to find out whether it is healthy is a request most of them should refuse.

Giving the connector its own error type is small and keeps infrastructure noise out of the findings, which is what makes the findings worth reading.