One fix, taken all the way to a live site and back.
SEO OS 3.1.4 working on our own homepage, slipperdigital.com. It reads the site's Search Console data, crawls it, drafts a change, checks the deploy folder against what the site really serves, publishes through the Cloudflare connector, and passes the change only after a recrawl sees it live.
3 minutes 34 seconds · silent · 4.3 MB, nothing loads until you press play
Search data first, then a crawl of the live site.
The run starts from three months of the site's own Search Console export, 1,000 pages of it, then crawls slipperdigital.com as it is served. Crawl findings and search findings land in separate inboxes; nothing enters the diagnosis until the analyst accepts it.
Checks that found nothing, on a crawl that covered the whole site, are passed automatically, each with a note of exactly what was checked. Fourteen were passed that way here.
- Search Console pages
- 1,000
- Impressions
- 9,923
- Clicks
- 12
- URLs crawled
- 35
Site Audit · crawl complete
The homepage ranks, and nobody clicks.
The finding that matters: the homepage sits at position 7.2 with 65 impressions and no clicks, where a page at that position would normally earn about 4%. The rule compares every page ranking between 4 and 15 with the expected click-through curve.
This site is young, and no page reached the rule's usual 500-impression floor. SEO OS 3.1.4 sets the floor from the site's own data instead, here 48 impressions, and says so in the finding, so nobody mistakes a small sample for a big one. Before 3.1.4 the check could never fire on a site this size.
- Position
- 7.2
- Impressions
- 65
- Click-through
- 0% vs ~4.2%
- Floor used
- 48 impressions
Search Intelligence · search findings
Two drafts. One approved, one rejected.
Accepting the finding produces two drafts for the homepage. The title draft moves the topic ahead of the brand. The description draft claims the current description does not reflect the page, which is not true here: the live one already describes it.
So the title is approved and the description is rejected. Drafts are proposals, never actions; only an approved proposal can reach a change set.
- Title, now
- Slipper Digital | Knowledge…
- Title, proposed
- Knowledge… | Slipper Digital
- Title
- Approved
- Description
- Rejected
Optimization · draft proposals
Before anything is published, the folder is compared with the live site.
Publishing to Cloudflare uploads the whole deploy folder, not one page. So the dry run fetches every file the live site serves and compares it with the folder. If anything on the live site were newer, publishing would overwrite it, and the dry run would stop.
All 80 files matched. The 33 live URLs from the crawl were also checked for pages the folder would delete. Then the current title was saved as a snapshot, so the change could be undone exactly.
- Files compared
- 80
- Matched live
- 80
- Deletion check
- 33 URLs
- Snapshot taken
- 1 value
Execution · dry run passed
Published, then passed only because the live page says so.
The connector publishes the folder to Cloudflare. A successful upload is not treated as success: SEO OS recrawls the homepage and passes the change only when the live page carries the approved title, and runs its other production checks on the same fetch.
Twelve seconds after the publish, the recrawl passed. The deployment links to the Cloudflare version it created.
- Cloudflare version
- cd536509
- Recrawl checks passed
- 8 of 8 applicable
- Publish to pass
- 12 seconds
- Status
- Validated
Execution · validated in production · frame from the recording
Then the change was undone, and checked again.
This was a test on our own homepage, so it was rolled back. Rollback restores the saved value, publishes again through the same connector, and recrawls to confirm the original title is live. It was: the title was live on the site for under a minute.
This step is not in the recording; see below for why. It is in the change set's log, with times.
- Validated
- 17:29:10 UTC
- Rolled back
- 17:29:50 UTC
- Rollback verified
- 17:30:02 UTC
- Site afterwards
- As before
What the recording shows, and what it does not
- The rollback happened after the recording ends. The script that drives the app stopped on a check it could not make from inside the app window, right after validation. SEO OS's safety step then rolled the change back through the same connector and verified it by recrawl. The video ends on "Validated in production"; the rollback is in the log only.
- Some setup was done off camera, on purpose. The Cloudflare connector was configured before recording, so the deploy folder's path and the account's names are never on screen, and the app was connected to its local service before the window opened. The deploy folder and the live site were both backed up first.
- The clicks are scripted. A script drives the real app so the run can be repeated exactly. The decisions it carries out (approve the title, reject the description) were made by the analyst after reading both drafts.
- Steps one to four show screens from a second, identical run the same evening, captured as clean screenshots. It used the same site and data, produced the same drafts, matched 80 of 80 files, and was also validated, rolled back and verified. The video, and the step five screen, are the first run.
- The search numbers are small, and real. They are the site's own export. The title change was a test and is not live; this page does not claim it would lift clicks.
- This proves the Cloudflare connector on a live site. It does not prove the other connectors: WordPress, Shopify, GitHub and webhook targets are still described on the sales page as not live-tested.