Building my own WordPress theme and taking control of the stack

I had a WordPress theme that did a lot of things well. It was flexible, polished and capable of supporting far more layouts than I needed. The problem was that all that flexibility came with weight, and every time I wanted to change something fundamental I had to work around a system designed for everyone else.

I have now replaced it with my own theme, Interlinker Journalist. It is built to work with the publishing and management plugin I have been developing, and it has made me think more broadly about how much of a website I can reasonably own and maintain myself.

Why build a theme?

The paid theme was good at being a general-purpose product. I wanted a site with a narrower set of requirements and more direct control over how it met them. Its features and styling added weight, and fixes were difficult to make at the source: editing a vendor’s theme directly risks having those changes overwritten by an update. WordPress provides ways to customise a theme without editing it, but each workaround adds another layer to understand and maintain.

With my own theme I can change the PHP templates, CSS and JavaScript directly. I can remove features I do not use, decide how content is rendered and fix an issue at the point where it originates. I can also use an MCP-assisted workflow to make changes without navigating a large visual editor. That control has been more useful to me than having a catalogue of options I rarely need.

Making the theme and plugin fit

The plugin has grown beyond publishing into Q&A, internal linking and SEO. A general-purpose theme cannot necessarily know how I want those pieces presented. Interlinker Journalist has dedicated templates for questions and answers, giving the theme a direct role in their layout instead of depending on content filters to insert a complete interface into a page.

The theme can also use the plugin’s related-content functions and provide its own styling for the results. Having both sides under my control makes it easier to keep the presentation consistent and investigate clashes. For SEO, it means I can consider the metadata and the rendered page together, validate the output and change either side when something is wrong. It does not guarantee a search ranking, but it makes the technical work much easier to manage.

The performance result

In my current Google checks, the uncached page is now green across the board. That is a significant improvement from the experience that prompted the change. I do not have a controlled set of before-and-after figures to publish here, so I cannot attribute a precise saving to individual changes.

The theme keeps the front end focused on the site’s needs. Its stylesheet is inlined when available, and its theme JavaScript is deferred. Those choices are specific to this implementation rather than a universal recipe: what helps depends on the page and how it is delivered.

I expect caching to make delivery faster still, but that needs its own measurement. My suspicion is that network latency may now be a more meaningful part of the remaining wait than rendering the HTML and styles. That is the next question to test, not a result I can claim yet.

Owning more of the stack

This is becoming a broader experiment in building a sustainable WordPress site with fewer third-party dependencies. I had been looking at paid SEO features too: Yoast’s premium offering put capabilities I wanted behind a subscription. My own plugin now handles the SEO work I need and lets me extend it with language-model-assisted tools. I am not claiming feature-for-feature equivalence; the benefit is that I can build around my own workflow.

There is a financial attraction. The paid theme and premium plugin subscriptions are costs I can potentially remove, while my ChatGPT subscription is useful to me for other work as well. That does not make the software free: development, hosting, model use and maintenance still cost time or money. The question is whether the control and reduced recurring fees justify that investment for my sites.

There is a security angle too. A private, bespoke codebase is less exposed to automated attacks aimed at a known vulnerability in a widely installed plugin. It is not secure simply because its source is private: mistakes in my own code, dependencies and configuration can still be exploited. Owning the code also means owning the responsibility to review it, patch it and keep it running.

I am very happy with the theme decision so far. It has improved the site’s performance in the checks I have run and made the relationship between the publishing system and the front end much easier to shape. It has also raised an interesting next question: which other subscriptions are worth replacing with software I can build and maintain myself?