A public static site attracts steady 404 traffic; most of it is bot/scanner noise (probing for WordPress and PHP admin paths that don't exist here) and should stay 404. The actionable kind is internal: links, sitemap entries, or crawler-file URLs that don't resolve. The main actionable case found — older /changes/{version} pages that 404'd because per-version HTML is capped to the latest few — is fixed: those now redirect to the change index, and the version timeline no longer links non-existent HTML pages. This page documents the policy, the deployment-automation reconciliation, and the crawler posture; it exposes no logs, IPs, or secrets.
- Bot probes (e.g. /wp-admin/install.php) are expected and stay 404 — no action.
- Older /changes/{version} now 308-redirects to /changes; unknown versions still 404.
- Crawler files (robots, sitemap, llms.txt, route catalog) list only valid URLs.
- Deployment/ABIU truth is reconciled by observing whether a push auto-promotes.
Bot probes are expected — focus on internal linksWordPress/PHP probe paths (e.g.
/wp-admin/install.php) should remain 404 — that is the cheapest correct response, and Warconomy never builds admin-like pages or redirects that make a probe look successful. Effort goes to internal broken links and sitemap correctness, not to chasing random external 404s.404 / error classification
| Pattern | Class | Likely cause | Action | Status |
|---|---|---|---|---|
| /wp-admin/*, *.php probes, /xmlrpc.php, common CMS/admin paths | Bot / scanner noise | Automated scanners probing for WordPress/PHP installs. Warconomy is not WordPress and has no admin surface. | Leave as 404 (the cheapest correct response). Do not build admin-like pages or redirects that make a probe look successful. | handled |
| /changes/{version} for older, non-materialized versions (e.g. /changes/1.96.0) | Stale version URL | Per-version HTML detail is capped to the latest few versions (build-cost cap); older versions are JSON-only. A page once linked every version's HTML page unconditionally, and crawlers cached those URLs. | Fixed at the source: the version timeline now only links HTML detail where it exists, and the change index links older versions to their frozen JSON — so no internal link points to a non-materialized version page. Older /changes/{version} return a clean 404, which is acceptable stale-crawler noise (a redirect was tried but App Hosting coalesced the Location header for dynamic segments). | handled |
| Internal hrefs / sitemap / llms.txt / route-catalog entries that don't resolve | Broken internal link | A page, export, or crawler file pointing at a route that isn't generated. | Audited by tests: the sitemap contains only materialized /changes/{version} entries, and the broken-link audit checks discovery pages and crawler files. None outstanding. | handled |
| Random one-off 404s (typos, truncated URLs, link-rot from other sites) | Acceptable background | Normal background noise for any public site. | Acceptable. Focus effort on internal links and sitemap correctness, not on chasing every external 404. | handled |
Deployment automation (ABIU) reconciliation
- Mechanism: Firebase App Hosting builds each commit on main via Cloud Build, then promotes a serving rollout.
- Observed: The Firebase Console shows 'Automatic rollouts: Enabled' while `apphosting:backends:list` reports the ABIU column as 'Disabled' — the two track different things and the CLI value lags. A behavioral test confirmed the Console is correct: a push auto-promoted a brand-new route to production (~9 minutes) with no manual rollout.
- How we know the truth: Auto-rollout is confirmed working: push to main and the new revision promotes itself. The manual `apphosting:rollouts:create --git-branch main --force` is the documented fallback if a future push ever stays stale, but is no longer needed for normal deploys.
- Settings: No Firebase settings are changed from the repo.
Crawler hygiene
- robots.txt: Allows crawling of public pages and references the sitemap.
- sitemap.xml: Lists only valid public URLs; per-version change pages are limited to the materialized set.
- llms.txt: Points AI tools at valid public and machine-readable URLs only.
- route catalog (/routes): Enumerates real routes; new routes are added with their data exports.
- legacy /monitors/* redirects: Still 308-redirect to their canonical topic pages.
Mobile
- Document-level horizontal scroll is prevented (html overflow-x:clip); the top nav and wide tables scroll inside their own containers.
- Guarded by the mobile-overflow CSS test.
What Claude can re-check later (no manual input)
- Re-run the broken-link / sitemap-validity audits after any route change.
- Confirm only materialized /changes/{version} appear in the sitemap.
- Confirm robots.txt references the sitemap and llms.txt URLs resolve.
- Re-confirm ABIU truth by observing whether a push auto-promotes.
Next manual action: Confirm whether automatic rollouts are truly enabled (watch whether the next push auto-promotes). If not, re-enable ABIU in the Firebase console — a deliberate setting change. Search Console / Bing setup remains a manual step.
Related
Operator workbench · Backlog · Automation readiness · Indexing checklist · /operator/production-health/data.json