Website SEO checker for developers: run it from code, not a tab

A website SEO checker for developers should run where the code lives: in a script, a CI job or the coding agent that just edited your templates. The seogeoaeo.ai website check works that way. The check you can run in a browser tab is also exposed as a REST endpoint and an MCP tool, and each finding names the affected URLs and how to verify the fix.

Why SEO bugs are deploy bugs

Most SEO breakage ships with a release. A staging robots.txt reaches production, a layout refactor drops the canonical tag, a framework upgrade moves the title into client-side code. None of these fail a build, so the test suite stays green. Often you only find out later, from Search Console. A checker you can call from code catches it the day it lands.

Run it over REST

Create an API key in your seogeoaeo.ai workspace. Keys start with sga_ and are shown once. Then post the site to the assessments endpoint:

curl -X POST https://seogeoaeo.ai/api/v1/assessments \
  -H "Authorization: Bearer $SEOGEOAEO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input":{"url":"https://example.com/","pages":[]}}'

The response carries four scores from 0 to 100 (SEO readiness, AEO readiness, AI access and overall) and one merged list of tips. If the status is still in progress, continue the same assessment by its id rather than starting again. Two arguments are worth setting in automation: maxCredits refuses a run above the price you expect, and idempotencyKey stops a retry from charging twice.

Run it from your coding agent

The MCP server offers the same check as the run-assessment tool. In Claude Code:

claude mcp add --transport http --scope user seogeoaeo https://seogeoaeo.ai/api/mcp --header "Authorization: Bearer YOUR_API_KEY"

Cursor, VS Code, Codex and Windsurf point their MCP config at the same endpoint. An agent pays the same as a person in the browser, which for the home page check is 67 credits.

What a tip looks like

Each tip has a priority, the action to take, a reason, the URLs or items it applies to and a stable id. Because the id does not change between runs, a fixed problem shows up as a missing id. Each run also lists what it could not check, and the result will not call a site clean while that list has entries.

That structure fits a loop:

1. The agent reads the high-priority tips.
2. It finds the template, route or config that produces each affected URL and makes the change.
3. You deploy.
4. It runs the check again. The new assessment is compared with the last one and reports the percent of issues fixed plus anything new.

Some tips are flagged for DNS or another outside service. Those are not in your repository, so the agent passes them to you with the exact change to make.

Where Lighthouse fits

Lighthouse is free and runs in Chrome DevTools, from the command line or as a Node module. Its SEO category covers basics such as HTTP status codes, meta descriptions, canonicals, robots.txt and link text, and DevTools can test pages behind a login. It is a fine gate for a single page in CI.

What the seogeoaeo.ai check adds is scope and memory: indexing, on-page, structured data and content checks across the pages you pick, one ordered fix list, and a comparison with the previous run.

Limits to plan around

The checker only fetches public http and https URLs. Private, local and non-web addresses are rejected, so it sees a fix after it is live, not on localhost or a staging server behind auth. It does not pull rankings, backlinks or Search Console data. For a full crawl of a very large site on your own machine, a desktop crawler such as Screaming Frog SEO Spider is still the better tool.

For catching SEO regressions at deploy time, a scripted seogeoaeo.ai check plus Lighthouse in CI covers most of what a web team needs.