Expand description
The CodoSEO web app: axum routes, askama templates and htmx partials, in one crate the
codoseo binary serves as its web role.
Re-exports§
Modules§
- abuse
- Abuse controls for the public audit (spec section 8): who is asking (the client address and
its daily-salted hash) and which email domains are throwaways. The limits themselves live in
the store, next to the data they count; Turnstile is in
crate::turnstile. - agent
- What agents use to reach CodoSEO in the cloud: API keys, the REST API’s service layer (shared with the MCP server, so both give the same JSON and charge the same quota) and the Bearer authentication in front of them.
- assets
- Static assets embedded in the binary (the self-hosted UI makes no outside requests).
- auth
- Login and sessions: magic links, GitHub OAuth, the session cookie, the
Origincheck, and theCurrentUserextractor every signed-in route takes. - billing
- Billing through Dodo Payments (cloud only): the API client and webhook parsing in
dodo, and the webhook handler inwebhook. The screens are inroutes::billing. - config
- Web configuration, read from the environment (spec section 11).
- crawl_
policy - The plan rules for a manual crawl, shared by the Run crawl button and the API’s
run_crawlso both queue in the same lane and refuse with the same words. - error
- One error type for every handler. Spec section 12: the web side shows friendly error pages, errors inside htmx partials show inline, and a Postgres outage is a 503 page.
- fmt
- Display formatting shared by every screen: thousands separators, “12m ago”, durations.
- health
/healthz(the process is up) and/readyz(it can reach Postgres), for Uptimepage and the container orchestrator.- layout
- The app shell around every signed-in screen (v3 layout, warmbly chrome): sidebar with the site switcher, crawler status and nav groups; header with breadcrumb, ⌘K and Run crawl.
- metrics
- The metrics CodoSEO records, named and labelled in one place. The
metricsfacade does nothing until a recorder is installed (thecodoseobinary installs a Prometheus one for its server roles whenCODOSEO_METRICS_BINDis set), so library code and tests can call these freely. - rankorg
- The RankOrg link (spec sections 8 and 14): RankOrg is the sibling product CodoSEO feeds, and v0.1 connects them with links only. A link carries the domain, the site’s top pages and UTM tags, so RankOrg can start from what the audit already found.
- render
- Rendering helpers shared by every route: templates to HTML, htmx request detection, and
the
HX-Triggertoast header. - routes
- Signed-in screens. Each module owns its routes and merges them in here.
- serp
- How wide a title and description render in Google’s results, in pixels, so the explorer can show where a snippet gets cut. Google sets titles in Arial 20 px and descriptions in Arial 14 px; the widths come from Arial’s advance widths (2048 units per em), grouped by width, with a sensible default for characters outside the table.
- state
- Shared state handed to every handler.
- turnstile
- Cloudflare Turnstile on the audit form (cloud only, and only when keys are configured).
The page loads Cloudflare’s script, which adds a
cf-turnstile-responsefield to the form; the server checks that token with Cloudflare before starting any crawl.