Documentation
Reviewing and applying fixes
The core loop: review, apply, verify, measure. And undo it if you change your mind.
The workflow
- Review the recommendation. It names a page and a specific change
- Understand the fix. Original value, suggested value, confidence, and the method that would deliver it
- Preview it before anything goes live
- Approve it
- Apply it through your CMS, the edge, the snippet, or a pull request
- Verify it — see below, this step is the one people skip
- Re-scan. The issue should be gone
Where a fix actually lands
This is the most important thing on this page, and the most common source of confusion. The four delivery methods are genuinely different, and only two of them change what a search engine sees when it fetches your page.
| Method | What changes | Search engines see it? |
|---|---|---|
| CMS | Your CMS record, so your origin HTML | Yes |
| GitHub pull request | Your page's source file, once merged | Yes, after merge |
| Edge | The response Crawlix proxies — not your origin | Only via the proxy |
| Snippet | The page in a visitor's browser | No, if the crawler does not run JavaScript |
Every applied fix carries a badge showing which method delivered it, because these are different claims about your site. When a content change cannot reach your origin, Crawlix refuses to publish it rather than putting it where it will not count.
Verifying a change
Do not just look at the page in your browser — your browser runs the snippet, so it can show you a change a crawler will never see.
Instead fetch the raw page. In a terminal: curl -s https://yoursite.com/page | grep "<title>". Or use your browser's "view source" — which shows the origin HTML — rather than the inspector, which shows the page after JavaScript has run.
Worth knowing
If the fix was delivered by CMS or a merged pull request, it will be in the source. If it was delivered by the snippet, it will not be, and that is expected behaviour rather than a failure.
Re-scanning
Run another scan after applying a batch of fixes. Issues you resolved should disappear. Anything still reported was either not delivered to a surface the crawler reads, or not actually fixed.
Change history
Every change Crawlix makes is recorded with what it was, what it became, which method carried it, how confident it was, and what it predicted would happen.
After a measurement window closes, the record gets a verdict: improved, regressed, or no change.
Be careful here
Read the regressions. They tell you which fix types work on your specific site, which is far more useful than any average. A change history where everything improved is one you should not trust.
Reverting a change
Three options, all from the change history:
- Revert a single fix
- Revert several at once
- Revert every change on one page
Reverting restores the previous value through the same method that applied it. If you revert something, that is useful signal rather than a failure — it tells us the confidence score was wrong.
A note on content changes
Crawlix will never publish body content automatically, whatever your settings. Content fixes always require your approval, and through most CMS integrations they cannot be delivered at all — only the GitHub pull-request route can write body content.
The reasoning: a fabricated statistic published on your domain is your publication, under your name. That is the failure this product exists to remove from the web, not add to it.
Next: Autopilot, if you want some of this to happen without asking you each time.