Saving a local newspaper’s digital presence
A headless rebuild of Easy Reader News — from a failing WordPress monolith to enterprise-grade infrastructure. Three weeks after launch, real traffic is up roughly 95×, user-experience issues have collapsed to 0.07% of sessions, and subscriptions have gone from one every two weeks to about a hundred a day.
A community newsroom on ageing infrastructure
Easy Reader News is a local newspaper with a long print heritage and a small, tenured team. Their digital platform had been rebuilt before — always on WordPress, and always growing more fragile. Each version added more plugins, more templates, and more ways to break. By early 2026 the site was expensive to host, difficult to maintain, and painful to use.
The platform timeline
- 2011 — Original site. WordPress.
- 2017 — Redesign. WordPress.
- 2025 — First rebuild, built to the client’s dictated styling and against our recommendation. WordPress.
- April 2026 — Project approved to rebuild and save the paper’s digital presence.
- 2026 — New headless build launched. Live today.
Everything that can go wrong on a WordPress monolith, was
The prior build ran as a single, plugin-heavy WordPress application on an Azure IaaS server behind a Cloudflare CDN. On paper, fine. In practice the plugin stack was doing the heavy lifting, and buckling.
Leaky Paywall, literally
Subscriptions ran on the Leaky Paywall plugin. Its PHP layer threw errors and access rules were inconsistent — paying readers hit friction while the paywall itself let content slip through. Conversion was near zero: roughly one sign-up every two weeks.
Elementor template strain
Posts were assembled at request time through Elementor templates. Every page view meant PHP rendering a heavy template tree — slow, brittle, and a constant source of layout and performance failures.
Rogue child processes
Poorly supported plugins spawned child processes that consumed server resources and never cleaned up — degrading performance and creating pressure toward costly spec upgrades just to keep the site standing.
An expert team, a hostile CMS
The newsroom is tenured and excellent at journalism, not at fighting a fragile, ever-shifting admin. The realistic goal was never to teach everyone a new complex system. It was to give them a simple backend and move the complexity elsewhere.
Upgrading the server specs to brute-force past these problems did not make financial sense for a local paper. The plugins were the problem, not the horsepower — so we changed the architecture instead of the invoice.
What “user experience issues” actually means
We track real user behavior with Microsoft Clarity, which records anonymised sessions and heatmaps. Beyond page views, Clarity flags frustration signals — moments where a real person struggled — and reports the share of sessions containing one or more of them. That percentage is an honest, user-side quality score.
- Rage clicks — rapid, repeated clicks in the same spot: the digital body language of “why isn’t this working?”
- Dead clicks — clicks on things that look interactive but do nothing: broken buttons, unresponsive links.
- Quick backs — a visitor lands, then immediately bounces back. The page failed them in seconds.
- Excessive scrolling — frantic hunting for content that should have been easy to find.
- Script errors — JavaScript throwing errors mid-session, often the invisible cause of everything above.
- Session issue rate — the headline number: the percentage of all sessions containing any of the above. Lower is better.
Two builds ago, 87% of sessions hit a problem. The client-dictated rebuild cut that to 19.8%. The new headless build sits at 0.07% — roughly a 1,240× reduction in user-facing friction against the original, and about 283× against the build it replaced.
A headless architecture: keep WordPress, remove its burden
We did not throw WordPress away — the team knows it. We shrank it. WordPress now runs as a small, familiar backend where writers do one thing: publish. Everything the public touches is served by a fast, hand-built front end. Content passes through a GraphQL layer, the front end is designed in Figma and built by hand, and a new in-house paywall talks directly to Stripe.
How a story travels from newsroom to reader
- WordPress, headless — a smaller instance. Writers publish exactly as before. No page building, no Elementor.
- GraphQL layer — passes posts and SEO metadata to the front end on demand. Clean, typed, cacheable.
- Hand-built front end — designed in Figma, built by ALCO. No per-request PHP rendering. Served through Cloudflare.
A paywall we own
Leaky Paywall replaced by an in-house paywall wired straight to Stripe. No third-party plugin between the reader and payment: fewer failure points, a cleaner checkout, and full control of subscription logic.
Design-led, not plugin-led
The front end is designed in Figma and hand-built. Layout is intentional and consistent, not a page builder guessing at templates. That is why the UX-issue rate collapsed.
SEO through GraphQL passthrough
Posts and their SEO metadata flow to the front end via GraphQL, giving search engines clean, fast, structured pages. RSS continues to be served from WordPress for existing syndication.
Same footprint, better result
Still Azure IaaS behind Cloudflare, on the same specs. Zero PHP errors and zero rogue child processes — achieved by removing work, not by buying capacity.
The platform is also wired into our own monitoring and automation, so problems surface and are resolved as routine maintenance rather than as emergencies.
The numbers after launch
Every figure below excludes bots and reflects real human traffic and behavior.
From about 1,900 a day on the legacy build to 180,000 on the new one — roughly 95× the daily audience, and about 20,000× the earliest measured traffic.
From roughly one sign-up every two weeks to about a hundred a day — 90 annual and 10 weekly — which is approximately 2,100 new subscriptions in the first three weeks.
Before and after, at a glance
| Metric | Legacy WordPress build | New headless build | Change |
|---|---|---|---|
| Real visitors per day | ~1,900 | 180,000 | ≈ 95× more |
| Sessions with UX issues | 19.8% (87% prior) | 0.07% | ≈ 283× fewer |
| New subscriptions | 1 every 2 weeks | ~100 per day | ≈ 1,400× more |
| PHP errors | Recurring | 0 | Eliminated |
| Rogue child processes | Recurring | 0 | Eliminated |
| Paywall | Leaky Paywall plugin | In-house, Stripe direct | Owned end to end |
| Server cost footprint | Upgrade pressure | Same specs | No upgrade needed |
What this means if you are just here to read the news
You do not need to know what “headless” means to feel it. Here is the difference, without the jargon.
The old way
- Every time you opened a page, the server rebuilt it from scratch using a stack of plugins — slow, and prone to breaking.
- Buttons that did not respond, layouts that shifted, and a paywall that frustrated the people trying to pay.
- When a plugin failed, the whole site felt it.
The new way
- The pages you read are pre-built and fast — the heavy work happens behind the scenes, not on your screen.
- A smaller, simpler WordPress just holds the articles. A separate, purpose-built front end delivers them.
- Subscribing is a clean, direct checkout through Stripe. It works.
We kept the part the newsroom knows, made it smaller, and let a modern engine do the heavy lifting. Faster for the reader, simpler for the team, and solid underneath — zero PHP errors, zero runaway processes.
Enterprise-grade infrastructure, built for a local paper.
Easy Reader News now runs on architecture you would expect from a major digital publisher — engineered, deployed and maintained by ALCO USA for a community newsroom in its own backyard. If your platform is fighting you instead of working for you, we should talk.