Most British WordPress work is inheriting somebody else's site
Most WordPress work we are asked for in Britain is not a new build. It is taking over a site somebody else made: finding out what is in the theme, which plugins do what they claim, why the consent banner blocks nothing, and who has been responsible for updates, which is usually nobody.
A site arrives with a login, a theme nobody documented, and a plugin list that grew by accretion. The agency that built it has moved on, changed hands or simply stopped replying. Nothing is obviously broken, which is why it has been left alone, and that is why the problems surface at the worst moment.
The consent banner catches people out most often. A plugin was installed, a banner appeared, and everyone assumed the job was finished. Then somebody opens the browser's developer tools before accepting anything and finds trackers already running, because the banner presents a choice that was never wired to the scripts. The theme has its own trouble: custom code built to a design that never considered contrast or focus, now failing the accessibility requirement in a public sector tender. Underneath both, updates have been deferred so long that applying them has itself become the risky operation everybody avoids.
When this work makes sense
Questions worth asking any supplier
Ask whether the first piece of work is an audit or a redesign, because anyone proposing a rebuild before looking has decided the answer without seeing the site.
Ask how the consent banner will be tested, because the only meaningful test is checking what actually loads before a visitor has agreed to anything.
Ask what happens to plugin licences registered to the previous agency, because renewals lapse silently and the first sign is a plugin that has quietly stopped updating.
Ask who applies updates once the project ends, because if that is not named it defaults to nobody, which is precisely how the site got here.
Ask whether the theme can be made accessible or has to be replaced, because that answer sets the budget and an honest supplier will tell you before quoting.
Deliverables
An audit of theme, plugins, hosting and update history, written for somebody who is not a developer
A tested consent configuration, verified by checking what loads before a visitor has agreed to anything
Accessibility fixes made in the theme itself, focus, contrast, headings, form labels, rather than by an overlay script
A plugin reduction: what is doing a job, what duplicates another, what has been abandoned upstream
Licences and accounts moved into your own name where they are currently held elsewhere
A staged update path from the current version, with a tested route back if something breaks
A named maintenance routine: who applies updates, how frequently, and who checks the site afterwards
Built with
Process
We change nothing to begin with. The first job is a read-only audit: what the theme actually contains, which plugins do work and which are dormant, what loads before consent, what the update history looks like, and where everything is hosted. That produces a list ordered by risk rather than by visibility. Very often the most urgent item is invisible to the client, an abandoned plugin with a published vulnerability, or trackers firing regardless of the banner, while the thing they asked about is cosmetic.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three ways to deal with an inherited WordPress site
Audit, then fix what matters
Fits: Most inherited sites, where the structure is sound and the problems are specific
Limits: You work inside somebody else's decisions, and some of them will constrain what is possible
Rebuild the theme, keep the content
Fits: Sites whose theme cannot be made accessible or is undocumented bespoke code
Limits: Costs considerably more than fixes and puts a working site at risk for a period
Leave it and plan a replacement
Fits: Sites due to be replaced anyway, where money spent now is money spent twice
Limits: Security and consent problems do not pause while you plan, so minimum maintenance is still required
Case studies
There is no published case study for this work yet, and no client site has been released as an example. Our London office is at 37th Floor, 1 Canada Square, Canary Wharf, London E14 5AA, and enquiries reach us at uk@mbgdesk.com. Takeover work will be published only with the client's permission to name them.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Our cookie banner is installed. Is that enough?
Test it before assuming. Install the plugin, see the banner, then check what loads before anyone has agreed to anything; on a great many British sites the trackers run regardless. The plugin supplies the interface, but something still has to hold the scripts back, and that step is routinely skipped.
The agency that built our site has gone. What do we have?
Usually less than you think, and it is worth establishing first. Plugin licences may sit on their account, hosting may be in their name, and the theme may be bespoke code with no repository. The commercial side of who owns what on exit is covered on our UK page; this is the technical recovery.
Can WordPress be made accessible?
Yes. WordPress is rarely the obstacle; the theme usually is. Core handles a great deal correctly, and then a theme strips focus outlines, uses headings for their size, and builds a menu that cannot be operated from a keyboard. Those are fixable. An overlay script claiming to fix a site automatically is not a fix.
How risky is applying updates deferred for years?
Riskier than applying them regularly, which is an argument for the routine rather than against the update. It is done on a staging copy, in stages, with a route back. The genuinely dangerous position is the current one: an unpatched site where deferral has become permanent because nobody wants to be blamed for an outage.
Do we need a maintenance contract, or can our team do it?
Your team can, if somebody is actually named and has the time. The failure is never capability; it is that maintenance belongs to everyone and therefore to no one. If nobody in-house will own it, a contract is worth having. If somebody will, we would rather set up the routine and hand it over.
Should we move off WordPress?
Often no. It is a reasonable choice for a content site that non-developers need to edit, and replatforming to escape neglect simply relocates the neglect. Moving makes sense when requirements have genuinely outgrown it, complex application behaviour, unusual integration, editorial workflows it fights, not because the current site is in poor condition.
How soon will we know what we are dealing with?
Quickly, because the audit is read-only and the serious findings appear early: the abandoned plugin, the consent configuration, the theme's accessibility position, the update backlog. What takes longer is the decision that follows, since fixing a theme and replacing one are different budgets.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.