Module routes 

Signed-in screens. Each module owns its routes and merges them in here.

Modules

account

/account: who is signed in, their plan, sign out, and (self-hosted owner) whether new people may sign up.

admin

/admin: the funnel, the quick-audit queue and failed jobs, for the people running the instance. In the cloud that is whoever is listed in ADMIN_EMAILS; self-hosted, the owner. Everyone else gets the same 404 as a page that doesn’t exist.

api

/api/v1: the REST API over the user’s monitored sites. Every route is a thin layer over AgentService, which the cloud MCP tools share, so both return the same JSON and count against the same daily quota.

audit

/s/{site}/audit: the site audit, the landing screen for a site. The health score and KPIs, every failing check, and the response-code, depth and response-time charts, all from the latest finished crawl. Before the first crawl finishes it shows that crawl’s live progress instead, refreshed from /s/{site}/audit/live.

billing

/billing: the plan, upgrading through Dodo Payments checkout, the customer portal, and choosing which sites stay monitored after a downgrade. Cloud only: on a self-hosted instance every route here is a 404 (and nothing links to them).

bot

/bot: what CodoSEObot is, so site owners can recognise, allow or block it. The crawler’s user agent points here.

changes

/s/{site}/changes: the latest finished crawl compared with the one before it. A diff summary, the changes themselves (filterable by severity with ?sev=), the health-score history and the default alert rules.

crawls

/s/{site}/crawls: the crawl history and Run crawl, which enforces the plan’s per-site manual allowance and the one-crawl-at-a-time rule; and /s/{site}/status, the sidebar crawler card’s poll, which announces a crawl that just finished.

explorer

/s/{site}/explorer: the URL explorer, modelled on Screaming Frog. Filters down the left (response codes, indexability, content type, failing checks), the URL grid with live search and infinite scroll, and a detail panel with four tabs: URL details, SERP snippet, inlinks and rebuilt HTTP headers. All state lives in the URL (?filter=&q=&sel=&tab=), so any view can be shared or reloaded.

export

/s/{site}/export.csv?filter=&q=: the latest finished crawl’s pages as CSV, with the explorer’s filter and search applied.

landing

The cloud landing page at /: one URL box that starts a no-signup audit.

mcp

/mcp: the cloud MCP server (streamable HTTP, stateless, JSON responses) in front of CloudMcp. Authentication is the API’s: Authorization: Bearer <key> and nothing else (a session cookie never counts). One endpoint serves both tiers: a request with a key gets the keyed tools, a request without one gets the no-key tools on the cloud and a 401 when self-hosted. A malformed, unknown or revoked key is a 401 JSON error, never “no key”.

monitoring

Two emailed links that act on a person’s behalf, and only once they press a button (mail scanners and link previews open every link, so a GET must change nothing):

quick

The no-signup audit (cloud only): POST /audit starts a 100-page quick crawl, /audit/{id} is the public report that walks from waiting through running to a score and the top five issues, and POST /audit/{id}/unlock emails a sign-in link that attaches the audited site to a new account and queues its first full crawl.

rankorg

/go/rankorg: counts a click and sends the visitor to RankOrg with their domain and top pages. Links on the audit preview and the explorer point here instead of straight at RankOrg, so every click lands in the funnel. Cloud only.

search

/s/{site}/search?q=: the ⌘K palette’s “Pages” section. app.js fetches it as you type and inserts the HTML as-is, so the response is only .pal-item links into the explorer (or nothing at all, and the palette shows its own empty state).

seo

/robots.txt and /llms.txt for the cloud domain. The static landing page used to serve them; now that the app owns /, it does. Self-hosted instances serve neither.

settings_alerts

/settings/alerts: where alerts go (the account’s channels) and which changes go there at once (the per-site rules grid). Everything not marked instant waits for the Monday digest.

settings_keys

/settings/api-keys: the keys agents use for the REST API and the cloud MCP server, today’s API usage and how to connect. A key is shown once, on the response that creates it.

sites

/sites: the account’s sites and the add-site form (onboarding when there are none).

Functions

router