Android Newswire: keeping WordPress, losing the theme
A news publication where editors work in WordPress exactly as before, while readers get a Next.js frontend and a mobile app — all served from one REST API.
- SECTOR
- Digital publishing
- ARCHITECTURE
- Headless WordPress
- SURFACES
- Web and Android
- LICENCE
- Commercial
- STATUS
- Live
Two requirements that normally fight
A news publication needs an editorial workflow its writers already know. WordPress wins that on familiarity alone — drafts, scheduling, categories, media, revisions, roles. Replacing it means retraining people whose job is writing, not learning tools.
The same publication also needs a fast, mobile-first reading experience and a native app. A conventional WordPress theme carries plugin CSS, jQuery, render-blocking assets and a rendering model designed in a different decade, and it produces HTML rather than data an app can consume.
The disagreement is not about WordPress. It is about the theme layer.
So we kept WordPress and removed only the part causing the problem. Editors publish as they always did. The theme no longer renders anything a reader sees. Content leaves through the REST API and is rendered by whichever application asked for it.
One content source, three surfaces
The economics of headless only work when there is more than one consumer. With three, the API stops being overhead and starts being the reason it is cheaper.
Unchanged for editors. Drafts, scheduling, categories, media library, user roles and revisions all work as before.
Server-rendered pages with category browsing and article views, built without inheriting theme or plugin frontend weight.
Consumes the same REST endpoints. New content appears in the app without a release, because the app renders data rather than shipping content.
What headless actually costs
Headless WordPress is usually sold as an upgrade. It is a trade, and anyone considering it deserves the other half of the ledger before they commit.
Preview breaks by default
WordPress preview renders through the theme, which no longer exists. Preview has to be rebuilt against the frontend, and if it is skipped, editors publish blind.
Frontend plugins stop working
Any plugin whose value is rendered output — related posts, share buttons, galleries, forms — produces nothing. Each one is either rebuilt or dropped.
SEO plugins output into a void
Yoast and similar write meta tags into a head the reader never receives. The meta values must be read from the API and rendered by the frontend, or the site ships with no metadata at all.
Two deployments, not one
WordPress and the frontend are separate applications with separate hosting, separate releases and separate failure modes.
Caching gets harder
Publishing no longer invalidates one cache. It has to invalidate the API response, the rendered page and any CDN copy, in the right order.
For a site with one web frontend, this is usually not worth it. For a publication feeding a website and a mobile app from the same newsroom, it is — which is exactly why we recommended it here and would not recommend it everywhere.
Why a news site cannot go headless carelessly
For a publication, organic search is not a marketing channel — it is the business. Most failed headless migrations fail here, and the failure is nearly always the same: the frontend renders on the client, so a crawler receives an empty shell, and the meta tags the SEO plugin generated never reach the page.
Next.js was chosen for server rendering specifically for this reason. Crawlers get complete HTML on the first request. Titles, descriptions and canonical URLs are read from the API and rendered server-side, so the values editors set in WordPress are the values that reach search engines.
The upside is real once that groundwork is right. Removing theme and plugin frontend weight improves the loading and stability metrics Google measures, and for a news site competing on freshness, speed compounds.
What the platform covers
Technology choices and why
Every choice here follows from one decision: editors should not have to change how they work.
WordPress
Retained because the editorial workflow is the part with the highest switching cost. Writers keep an interface they already know.
Next.js and React
Server rendering was non-negotiable for a publication dependent on organic search. Client-only rendering would have cost indexation.
WordPress REST API
Built into WordPress core, so no additional layer to maintain. The website and the mobile app consume identical endpoints.
Nginx
Routes between the WordPress backend and the frontend application, with caching at the edge.
How the team maintains it
GegoSoft engineers use Claude Code as standard daily tooling. On a headless build the repetitive work is the API client layer — typed models for every content type, response mapping, and the error handling for when the backend is mid-deploy and the frontend is not.
The decision to go headless, and the analysis of whether it was justified for this publication, were the team's. Every change passed normal review before merge.
Where it stands
Android Newswire is live at androidnewswire.com, publishing Android news, app launches, developer tooling updates and mobile gaming coverage across the website and the Android application.
EDIT-OUTCOMES — add measurable results here if available.
Common questions
Should we go headless with our WordPress site?
Probably not, if you have one website and no mobile app. The cost is real — rebuilt preview, lost frontend plugins, two deployments — and a well-optimised conventional theme is fast enough for most sites. Headless earns its keep when several applications consume the same content.
Does headless WordPress hurt SEO?
It can, badly, if the frontend renders on the client. Crawlers then receive an empty shell and the meta tags your SEO plugin generated never reach the page. Server rendering avoids this, which is why we used Next.js here rather than a client-only framework.
Can editors keep using the WordPress admin?
Yes, and that is usually the reason to choose headless over replacing the CMS. Drafts, scheduling, categories, media and roles all work as before. Preview needs rebuilding against the new frontend, and that should be in scope from the start.
Can a mobile app use our existing WordPress content?
Yes. The WordPress REST API is built into core, so an app can read your existing content without a migration. That is often the cheapest route to a content app.
What happens to our existing plugins?
Backend plugins keep working. Anything whose output is rendered HTML — related posts, share buttons, forms, galleries — stops appearing and has to be rebuilt in the frontend or dropped. Auditing that list is the first thing we do when scoping a headless migration.
Wondering whether headless is right for you?
Tell us what your site does and who publishes to it. We will give you a straight answer, including the common one — that a properly optimised WordPress theme would serve you better and cost less.
Start a conversation See all case studies