Every page passes on every score
- 90+lighthouse performance
- 100accessibility, every page
- 3/3agentic browsing
A platform site that scored like an abandoned one
The product was enterprise grade. The site in front of it was not. On the build that stood there, PageSpeed on mobile read Performance 56, Accessibility 89 and two agentic checks out of three, with a Speed Index of 10.5 seconds and 860ms of blocking time.
None of that shows up in a screenshot, which is why it survived so long. It shows up when a buyer on a phone waits, when a screen reader gives up, and when a model summarising the category quotes a competitor instead.
Underneath, the build was heavy and awkward to edit, so every fix cost more than it should have and most fixes were never made.
What changed, side by side
Before: Performance 56, Speed Index 10.5s
After the rebuild: 90+ on every page, mobile included
Before: Accessibility 89
After the rebuild: 100 on every page
Before: Two agentic checks out of three
After the rebuild: Three out of three
Before: Heavy build, edits cost more than they should
After the rebuild: A structure the team works in without us
What we did, in order
Measured before touching anything
Every page, not the home page: PageSpeed on mobile, the accessibility tree, and what an agent could parse. A site averages well and still fails page by page.
PageSpeed on the old build, mobile Rebuilt the page system around the collections it already had
Thirteen collections were doing real work behind a structure that made them expensive to use. The content model stayed. The way pages assemble from it did not.
Platform overview, assembled from collections Fixed accessibility as structure, not as a pass at the end
Heading order, focus, contrast and names built into the components, so a new page inherits them instead of being audited afterwards.
The same page at 390px Made the pages readable by machines as well as people
Clean semantics, one heading per level, answers written as answers. The agentic score moved because the markup did.
Handed the site back editable
A guide page lives inside the site itself, unindexed and reachable by link, so the team edits content without opening a ticket with us.
Three forks, two of them the CMS
Audit accessibility at the end of the rebuild, or build it into the components
Into the components: heading order, focus, contrast and names
Forty nine pages, and the site keeps adding them. A pass at the end has to be repeated for every page written after it, and the old build had already shown what happens then: when a fix costs more than it should, most fixes never get made. Inherited from a component, the structure arrives with the page instead of being audited onto it afterwards. That is why the score is 100 on every page rather than an average with the failing pages hidden inside it.
A new content model with the new build, or the thirteen collections that were already there
Kept the thirteen collections; rebuilt the way pages assemble from them
The collections were doing real work. What made them expensive was the structure around them, not the model, so replacing the model would have charged the rebuild for a part of the old site that was not the problem. Keeping it put the cost on the part that was, and left the content, and the people who write into it, untouched by the rebuild. It is also what makes the handover mean anything: the content model went back unchanged, with a guide page for it inside the site.
One FAQ block per page, or one collection that every page reads from
One collection, with each answer choosing the page it belongs to
The old build kept the FAQ inside each page as a component, so correcting one answer meant editing it everywhere it appeared, and nobody did. That is how the same answer ended up wrong across the product pages. One collection means an answer is written once, formatted properly, and appears wherever it belongs. It is the part of the site the marketing team now edits without asking us anything.
Blog Posts
- title
- body
- author
references Blog Categories
Blog Categories
- name
- slug
Guides
- title
- body
FAQ
- question
- answer
- page
Alternatives
- competitor
- body
AI Agents
- name
- body
Integrations
- name
- body
references Integration Categories
Integration Categories
- name
- slug
Team Members
- name
- role
Trust Items
- title
- proof
Academy Courses
- title
- body
Customer Stories
- client
- quote
Industries
- name
- body
Thirteen collections, forty nine pages assembled from them
Screens
Captured from the live siteHome Platform overview Integrations, from the CMS Blog Alternatives
What moved, and what it is measured against
- 49pages in the buildEvery one of them passes, not the average of them.
- 13CMS collectionsThe content model the team writes into, unchanged. What changed is how pages assemble from it.
- 3/3agentic browsingPageSpeed checks whether a machine can read and act on the page. The old build managed one of three.
- TBCsupport tickets deflectedNumber to confirm
Lighthouse, after the rebuild
- Performance90
- Accessibility100
What the client got, and in what form
- CMS editing guideOne page inside the site, unindexed and link only
- Ongoing supportContinuous since January 2025
- WebflowThe team publishes without us, which is what the rebuild was for.
- FigmaDesktop design arrived as handoffs from Chattermill’s own product designer. Mobile and tablet were drawn here, against those files.
- GSAPThe scroll work that native interactions cannot hold without becoming unmaintainable.
- HubSpotForms and lifecycle stay in the client’s own stack, so a lead never depends on us being awake.
- ClaudeQuick edits straight in the code, for changes that are faster typed than clicked.
- SlackOne shared channel with the client’s team, so a fix is asked for where it is answered.
Validation
100%Job Success
Top Rated
Webflow Certified Partner
2,200+hours on the platform
300+projects delivered
