WordPress

WordPress work that survives plugin bloat and page builders.

Most sites don't need a rebuild. They need the plugin list audited, the query count cut, and page-builder markup replaced by a theme that renders in one pass.

The brief, honestly

The site isn't slow. The stack bolted onto it is.

Nearly every WordPress brief arrives the same way. The site was fine at launch, then a plugin went in for a form, another for sliders, a third for caching to paper over the first two. Now the homepage fires more queries than it has content blocks, and the page builder ships markup nobody wrote by hand.

So we measure before we propose anything: plugin count against what each plugin actually does on a page, query count per template, and how much of the payload is page-builder overhead from Elementor, Divi, WPBakery or Oxygen. That baseline decides whether you get a custom theme or a cleanup.

10+ years of WordPress engineering sits behind that reading — custom themes and plugins, WooCommerce carts with real integrations, hardening and conflict resolution, hreflang and .htaccess rewrites for multi-region sites. Getting to 90+ PageSpeed is part of the work, not a separate invoice.

Problem 01

The homepage takes forever and nobody knows which plugin did it.

We profile per plugin and per template, so the answer is a query count and a payload figure rather than a hunch. Then we remove, replace or rewrite.

Problem 02

The page builder makes every edit slow and every page heavy.

We can keep Elementor and cut its overhead, or move the templates into a custom theme and leave the builder for landing pages. Your editors decide that, not us.

Problem 03

WooCommerce checkout falls over on sale days.

Cart and checkout get their own pass: query caps, object caching, and the third-party calls that block a purchase moved out of the request path.

Problem 04

Our developer vanished halfway through a rebuild.

We read the theme and the plugin list before touching either, then write down what is salvageable and what has to go. You get that verdict before we quote.

What's included

Scope, spelled out.

Custom theme development

Hand-built themes with template parts you can read, so a page renders in one pass instead of assembling itself out of shortcodes.

Custom plugin development

WordPress plugin work for the feature no marketplace covers, with a settings screen your team can use and code your next developer can follow.

Speed to 90+ PageSpeed

Plugin bloat removed, query count cut, assets deferred and images sized, until the Core Web Vitals field data stops flagging the page.

WooCommerce customization

Product, cart and checkout changes on WooCommerce, plus the payment, shipping and accounting integrations a real store needs behind them.

Page-builder overhead

Elementor, Divi, WPBakery and Oxygen builds trimmed or migrated, so page-builder overhead stops arriving in every visitor's payload.

hreflang and technical SEO

hreflang for multi-region sites, .htaccess rewrite rules, schema markup and the redirect map, written once and documented for whoever inherits it.

Hardening and diagnosis

Apache error logs read line by line, plugin conflicts isolated, and login or firewall plugins made to coexist instead of fighting each other.

How we work

What actually happens, week by week.

01

Baseline

Plugin list, query count per template and payload measured before anyone proposes a single fix.

02

Decide

Cleanup or custom theme, plugin by plugin, with every keep-or-cut call written down and priced.

03

Rebuild

Theme or plugin built on staging, bloat removed and queries fixed one reviewable commit at a time.

04

Vitals

A Core Web Vitals pass on the templates that earn money, not on the demo homepage, until field data settles.

05

Handover

Editor training on the real site, plus docs covering what we removed and why it should stay gone.

Tech stack

The tools we actually use here.

WordPress is the container, not the skill. This list is what goes inside one: the builders we work in, the commerce layer, and the AI pieces we shipped as plugins, not demos.

WordPressWooCommercePHPMySQLElementorDiviWPBakeryOxygenjQuerySCSSFroala WYSIWYGDeepSeekApache
What you get

Deliverables, outcomes and who this is for.

Deliverables
  • Plugin and query baseline report
  • Custom theme or plugin, on staging
  • Core Web Vitals before and after
  • hreflang and redirect map
  • Editor docs and a training session
Outcomes
  • 90+ PageSpeed on the pages that sell
  • Fewer plugins doing more work
  • Page-builder overhead off the payload
  • WooCommerce that holds on sale days
Ideal client

Marketing teams and agencies on WordPress or WooCommerce whose install has outgrown the plugin list holding it together.

Proof

Plugins we shipped, logs we actually read.

WordPress · AI

AI content scorer for Google E-E-A-T

SEO content tool (WordPress plugin)
WordPressPHPDeepSeekFroala
Outcomes
E-E-A-T
aligned scoring
Live
recommendations
No-code
plugin setup

Froala AI Assist, proxied safely

A WordPress plugin that calls DeepSeek from the server for Froala's AI Assist feature, so the provider credential never reaches the browser. Writing a plugin that talks to a model is ordinary work. Doing it without shipping the key to every visitor is the part worth checking.

Filestack: error logs, then plugin fixes

Apache error-log analysis for Filestack, followed by the plugin security fixes the logs pointed at. Reading logs is unglamorous and it is where the cause usually sits: a conflict, a fatal on one template, or something writing to the database on every page load.

hreflang, rewrites and the boring SEO

hreflang implementation for multi-region sites, .htaccess rewrite rules, Wordfence and WPS Hide Login made compatible with each other, and alt-text generation automation. None of it demos well. All of it is what a technical SEO brief actually asks for.

Frequently asked

Questions we get on the first call.

We work in them. Rebuilding a functioning builder site because we prefer hand-written templates would be charging you for our taste. Instead we measure what the builder costs per template, trim that, and move only the worst offenders into a custom theme. Your editors keep the tool they already know.

Sometimes, and you will hear which before you pay. 90+ PageSpeed is reachable on most content and commerce pages once plugin bloat and query count come down. It is not reachable while a booking widget, a chat script and three tracking tags all load in the head. The baseline tells you which case you are in.

Yes, the audit is billed. It is fixed-scope work producing a document you keep whether or not we build anything afterwards, and the plugin verdicts, query counts and priority order don't expire when the engagement does. Whether it credits toward a build is a conversation on the call. Ask us there.

You are, unless you keep us on for it — and that is the honest answer, not a disclaimer. What we can do is shrink the surface: fewer plugins, pinned versions, a staging site that mirrors production, and update notes telling whoever clicks the button what to watch. On a retainer, we click it.

That is most of what arrives here. We read the theme, the plugin list and the commit history before touching anything, then write down what is salvageable, what needs rewriting and what was never finished. Sometimes the verdict is that finishing the abandoned build costs more than restarting the theme. We say so.

Get the plugin list measured, not guessed.

Send the URL and your plugin list. We come to the first call with the query counts already taken, and no deck.