Claude
Rebuilt the site as static HTML and runs the scheduled automations: publishing, LinkedIn, Business Profile posts and PR triage.
A B2B consultancy whose website was invisible to AI search, and whose publishing, social and outreach all depended on one person doing everything by hand.
The short answer
The site was rebuilt from a JavaScript-only builder into static HTML, taking what crawlers could read from 39 bytes to 107 KB and 2,071 words, with nine AI crawlers explicitly allowed. It was then connected to a set of governed automations: a twice-weekly publishing run that writes, builds, publishes, verifies and requests indexing; a LinkedIn system posting five times a week from a self-replenishing queue; Business Profile posting; branded image generation; and a journalist-request triage flow that drafts replies but never sends them.
107 KB HTML crawlers can read, up from 39 bytes
29 Aug 2026
Before and after the static rebuild, Aug 2026
| Measure | Before | After |
|---|---|---|
| HTML returned to crawlers (KB) | 0.039 | 107 |
| Crawlable words on the homepage | 0 | 2,071 |
Scheduled runs, Sep 2026
| Item | Value |
|---|---|
| LinkedIn posts | 5 |
| Articles published and indexed | 2 |
| Business Profile posts | 2 |
Sep 2026
Want a result like this for your business?107 KB HTML crawlers can read, up from 39 bytes. Book a free 15-minute diagnostic and we will tell you what would move your number.
A crawl of what search engines and AI assistants actually receive, an analytics audit, and a map of every repeated weekly task.
One rule for every automation: a named owner, a human approval gate on anything that leaves the business, an audit log and a kill switch.
A static rebuild with one canonical host and 301s, schema on every page, an AI-crawler policy, a rebuilt GA4 property and DNS-verified Search Console; then the publishing run, the LinkedIn system, the image renderer, Business Profile posting and PR triage.
Runs on a schedule in the cloud, verifies its own output after every publish, requests indexing, and reports each run.
Rebuilt the site as static HTML and runs the scheduled automations: publishing, LinkedIn, Business Profile posts and PR triage.
Hosting: every published page is verified live and the cache cleared after each run.
The inbox the PR-triage flow reads and drafts replies into, for human approval.
A rebuilt property, so traffic from every channel is finally visible.
DNS-verified domain property; each new article is submitted for indexing the day it goes live.
Every new article is posted to the profile with a tracked link.
Five posts a week across four named series, each with a branded image.
What happens nextMove deployment to Git so no browser is needed in the loop, add IndexNow, and push enquiries into a CRM with a lead event in analytics.
Because the problem was the delivery, not the content. If crawlers receive an empty page, no plugin can fix it. Static HTML makes every word readable by Google and by AI crawlers that do not run JavaScript.
Only where the owner chose that. Anything that speaks to a third party, such as press replies, stops at a draft for human approval. Every run is logged and can be switched off.
It picks the due article, edits it to the house style, builds it in the site's design with schema, publishes it, clears the cache, verifies the live page, requests indexing, posts it to the Business Profile and shares it on LinkedIn.
Yes. It is the same pattern we use for clients: fix what machines can read first, then automate the repeated work with approval gates.
Next step