Home/How it works
How it works
One loop, run the same way every time: audit, snapshot, approve, deploy, verify, rollback if needed.
Nothing about it is magic. It is the careful sequence a good developer would follow by hand, automated so a business without a developer gets the same care.
[01] The loop
Six steps, in order, every time
- 1 Audit
We crawl your site the way AI systems do, as GPTBot, ClaudeBot, PerplexityBot and others. We test what your server does, not just what your robots.txt promises, and we record evidence for every check, pass or fail.
- 2 Snapshot
Before anything changes, we save the current state of whatever the fix will touch. A rule, a file, a setting. If there is no snapshot, there is no deployment. That rule has no exceptions.
- 3 Approve
You get a plain summary for each fix: what changes, why it matters, what could go wrong. You approve it or you do not. Silence is not approval, and a bundled yes to ten fixes at once is not how this works.
- 4 Deploy
The approved change ships through one of the two doors below. Small, specific, and logged. Not a redesign, not a migration, just the fix you approved.
- 5 Verify
We crawl again with the same bots and compare the new evidence against the audit. The fix counts as done only when the fresh crawl shows it working. You see the same before and after evidence we do.
- 6 Rollback
If verification fails, or you simply change your mind, the snapshot goes back and the change is gone. Rollback is a normal part of the loop, not an emergency procedure.
You can watch this exact loop run in public on the live demo page. We run it against a demo site we control, with the timeline open for anyone to read.
[02] Access
The two doors
Cloudflare first
Most high value fixes for a small site live at the edge: bot rules, firewall settings, bot management, and the robots file itself, served at the edge. Cloudflare is where those live, and changes there need no code deploy at all. That is why it is the first door. It is also free to join, and most customers need nothing more than the free plan.
GitHub second
Some fixes live in the codebase itself: the robots.txt file, or the head elements on the entry page. Those ship as pull requests in your repo, written the way a developer would write them, reviewed the way your team already reviews code. If you have no team, the pull request still shows you every line that changed. This is the newer door: it is built, and its first live pull request happens with the first GitHub connected site.
Together the two doors cover the large majority of what an audit finds. When a fix needs a door we do not have, we say so plainly instead of improvising.
[03] Commitments
What we never do
- We never promise citations or rankings. AI systems decide what to cite. We open the door and prove it is open. Anyone who guarantees you a citation is selling you a story.
- We never change anything without your approval. Access is not permission. Every change arrives as a proposal first.
- We never make a change we cannot undo. Snapshots come first, rollback stays available, and the record of what changed stays readable.
- We never keep access you have revoked. The tokens and keys are yours. Cut them and our access ends, while everything already deployed stays exactly where it is.
Ready to see where your site stands? Run the free audit. It takes a few seconds to queue and the results are yours to keep, whether or not we ever speak again.