Most American WordPress work is not building a site. It is taking one over
Most US WordPress engagements start with a site somebody else built. What makes them difficult here is the inheritance: plugins and licenses nobody can account for, accessibility gaps on a live site that have become a legal question rather than a quality one, and years of page-builder output that cannot simply be deleted.
American businesses have been on WordPress long enough that the typical site has passed through several hands. Each owner added what they needed and removed nothing. The result is not a bad site exactly; it is an undocumented one, with dependencies that nobody chose and nobody can safely remove. The work is archaeology before it is engineering, and pretending otherwise is how takeover projects break the thing they were hired to fix.
A marketing team asks for a small change and discovers nobody can make it safely. The premium plugins were bought on a former agency's account, so updates stopped when the relationship ended and the license renewals are going to an inbox nobody reads. The page builder holds the content inside its own markup, so a page cannot be edited without the builder and the builder cannot be removed without losing the page. Meanwhile the forms, menus and media carry accessibility problems that were a quality issue at launch and are now something the general counsel is asking about. Each of these is fixable. None is fixable quickly, and most takeover quotes assume otherwise.
When this work makes sense
Questions worth asking any supplier
Will the supplier produce a full plugin and license inventory before quoting, because a fixed price given without one is a guess that somebody will pay for later.
Who will hold the licenses after the engagement, because if they sit in the agency's account you are repeating the situation that brought you here.
Does the accessibility proposal remediate the templates and the content, because fixing a theme while published pages keep the same faults only moves the issue.
Is an overlay widget being offered as the accessibility answer, because that approach is contested and we would not present it as protection.
Does the plan say what happens to page-builder content, because leaving it, migrating it and rebuilding it are three very different budgets.
Deliverables
A full inventory: every plugin, its purpose, its update state, who holds the license and what breaks if it goes
Administrative account cleanup, with former agency and departed staff access removed and roles reduced
A restorable backup and a staging environment, proven by actually restoring rather than assumed
An accessibility audit of templates and representative content, ordered by severity and effort
Template remediation, plus a documented standard so the content team does not reintroduce faults
A page-builder decision with the cost of each route set out, then the chosen route executed
A maintenance policy naming who applies updates, on what schedule and who tests them
Built with
Process
We begin with an inventory and a restore test, not with fixes. The inventory answers what is installed, why, and what holds it in place; the restore test answers whether the backups anybody is relying on actually work. This order exists because the first substantive change on an inherited site is when you discover what the previous team wired together, and doing that without a proven rollback is how a routine update takes the site down for a day. It is also the stage that tells us honestly whether remediation or a rebuild is the cheaper path, which is a conversation better had at the start.
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 page-builder debt
Keep the builder, optimize around it
Fits: Sites where the content team is trained on it and the budget is limited
Limits: The license, the weight and the lock-in all remain, so the underlying cost is deferred rather than removed
Migrate content to native blocks
Fits: Sites with a manageable number of templates and repeatable page patterns
Limits: Slow, and pages with heavily customized layouts usually need rebuilding by hand anyway
Rebuild the front end, keep the content
Fits: Sites where the builder is the main source of both performance and accessibility problems
Limits: The largest budget and the longest timeline, and it needs the content team involved rather than informed
Case studies
No published US WordPress case study yet, and remediation work is rarely something a client wants named. Our New York office is at 1 Liberty Street, 23rd Floor. Client work will be published when we have permission and outcomes that can be evidenced rather than described.
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
Can you take over a site your team did not build?
Yes, and it is most of what we do on WordPress in this market. We ask for hosting, repository and admin access up front, then produce an inventory before committing to scope. If remediation would cost more than a rebuild, we say so at the inventory stage rather than after starting.
We received an accessibility demand letter. What now?
Speak to your attorney first, because the legal response and the technical response are separate tracks and only one of them is ours. On the technical side, the useful early output is an audit that documents what is wrong, ranked by severity, and a remediation plan with dates. We are not lawyers and cannot tell you what exposure you carry.
Will an accessibility overlay solve it?
We would not offer one as a solution. Overlay widgets are contested, they do not fix the underlying markup, and presenting one as protection is a claim we are not willing to make on your behalf. Remediation is slower and it addresses the actual templates and content. Your counsel is the right person to weigh the legal side.
How do we find out what our plugins are for?
By inventorying them and testing, which is unglamorous but there is no shortcut. Each plugin gets a purpose, an owner, an update state and a verdict: keep, replace, remove. The ones nobody can explain are tested on staging by disabling them and seeing what changes. Some are load-bearing in ways the site never documented.
Who should hold our plugin licenses?
You should, in accounts your organization owns, with the agency granted access rather than holding the keys. This is the most common inherited problem we see and it is the cheapest to prevent. When licenses sit with a departed supplier the updates stop, and stopped updates on a public site is a security matter rather than an inconvenience.
Is WordPress still the right platform for us?
Often yes, particularly where a content team publishes regularly and needs to work without developers. The general trade-offs are covered on our WordPress technology page. What is specific to a takeover is that the platform is rarely the problem, the accumulated decisions around it usually are, and those travel with you if you migrate without addressing them.
Can you make the site faster without rebuilding it?
Usually to a point, and it is worth doing before deciding on anything larger. Caching, image handling, script loading and removing unused plugins recover real ground. What caching cannot fix is a builder that loads its whole framework on every page. Once measured, we can say whether the remaining gap justifies the bigger project.
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.