Search and answer engines

How the collection’s AI SEO and AEO system works

The collection runs a loop rather than a checklist: read how every site performs in search and in AI answers, flag what is broken, fix it in code, then measure whether the fix did anything and let the result shape what comes next. This page walks the loop end to end.

The loop, step by step

Nine steps, in order. A control panel that watches every site in the collection runs them; a person approves the changes.

  1. Collect search data

    Google Search Console and Bing Webmaster Tools for how each site performs, SERP data from DataForSEO for where it ranks, Core Web Vitals for how it loads, and probes for whether AI crawlers can read the site and whether it publishes an llms.txt.

  2. Check AI answer engines

    For a set of tracked questions, ask Perplexity, Gemini and Google AI Overviews and record whether the answer cites one of our sites.

  3. Run the detectors

    A set of detectors reads the data above and flags specific, fixable problems on specific pages.

  4. Rank the fix queue

    Each finding becomes a proposed fix with a priority score, and the queue is ranked by that score.

  5. Send the daily fix email

    At 07:00 UTC every day the control panel emails the top of the queue as a digest an engineer can act on directly.

  6. Apply the fix in code

    A person approves, and the change is made in the site’s code. Each commit is tagged with the fix it implements and tied to the deploy that shipped it, so a fix can be followed from finding to live page.

  7. Verify after a measurement window

    After a waiting period the same data is read again and each fix is graded: worked, no measurable change, or regressed. Grading applies minimum-impression floors, so a page with too little traffic is not judged on noise, and it is cliff-aware: a verdict is marked confounded, and counted as neither worked nor regressed, when a sudden traffic cliff falls inside its measurement window.

  8. Feed outcomes back into priorities

    Outcomes re-weight future priorities by fix type: a type that keeps working moves up the queue and one that keeps failing moves down. Today that is a priority multiplier and nothing more. Deeper learning is planned, and this is not autonomous self-improvement.

  9. Monitor and alert

    Uptime monitoring on the sites, error tracking, Core Web Vitals drops and regression alerts raise a flag when something moves the wrong way.

AI on our own hardware

Language-model work in the loop does not go to a metered API by default. An LLM router sends a request to Hetzner's free inference tier first and falls back to models we host ourselves; a semantic cache sits in front of it so a question that has been answered before is not answered twice; and embeddings power semantic search across the sites.

The machines behind this are described, with their own measured figures, on the stack page.

Related

The machines and software this runs on are on /stack. How the sites behave day to day (uptime, deploys, backups and what is not working) is on /operations.