Why we don't take over other people's websites

We turn this work down regularly. Somebody rings up with a WordPress site that has gone slow, or broken on phones, or quietly stopped ranking, and asks whether we could have a look and sort it out. The answer is usually no.

That costs us money and it occasionally annoys people, so it seems only fair to explain the reasoning properly rather than hiding behind one line in the FAQs.

Nobody rings up asking for a big job. They ring asking for a small one. Can you make it load faster. Can you fix the contact form. Can you make the menu work properly on an iPhone.

None of those stay small once you open the bonnet. Making a site load faster means working out why it is slow, which means auditing however many plugins are installed, the theme, the hosting, the photographs somebody uploaded at four thousand pixels wide, and whatever custom code a previous developer left behind with no comments and no explanation.

By the time you understand enough to change the small thing safely, you have done most of the work of a rebuild, and charged a fraction of the price for it.

This is the part that settled it for us.

The moment we touch somebody else's site, we own it in the customer's mind. Three weeks later the contact form stops sending because of a plugin conflict that existed long before we arrived, and the phone call comes to us. Fairly, from where they are standing. They cannot see the line between the part we touched and the part we did not, and I would not expect them to.

So we either absorb the cost of fixing something we did not build, or we have an argument with somebody we like and will probably see in the Co-op. Neither of those is a business I want to be in.

There is a harder edged reason too. Patchstack, which tracks security issues across the WordPress ecosystem, recorded 11,334 new vulnerabilities in 2025, 91 percent of them in plugins. In 46 percent of cases the plugin developer had no fix available by the time the problem became public. For the vulnerabilities that get attacked hardest, the median gap between disclosure and the first exploitation attempt was five hours.

Now picture us agreeing to look after a site carrying twenty plugins, several last updated in 2021 by developers who have moved on to other things. We would have taken on responsibility for something we cannot actually secure. If it gets defaced, or starts quietly redirecting customers to a fake shop, our name is the one attached to it.

I would rather say no at the start than apologise in six months.

Turning a job down is not a shrug. It usually follows twenty minutes of looking, and a handful of specific things decide it.

How many plugins are installed, and how many are still actively maintained. Whether the theme is a commercial one that has been modified, which makes every future update a gamble. Whether there is any version control at all, or whether five years of changes were made by editing files directly on the server. Whether the hosting is somewhere we could reasonably work. And whether anybody alive knows what the custom code is for.

Two or three of those going the wrong way and the honest price for making the site safe is higher than the price of starting again. At that point recommending the patch would be doing you a disservice, even though it would be easier to sell.

There are exceptions, and I would rather list them than pretend we are absolutists about it.

• A genuinely contained job with a clear edge to it. Adding a page, swapping photographs, changing text on a site that is otherwise healthy.
• A site already built on something we know well, where we can read the whole thing in an afternoon and understand it.
• Something urgent and human. If a site is down and somebody's business has stopped, we will help get it back up and have the longer conversation afterwards.
• A health check. We will look at anybody's site and tell them what is wrong with it, for free, without touching a thing.

That last one matters more than the others. Refusing to take a site over is not the same as refusing to help. A fair number of health checks end with us telling somebody their website is fine and they should spend the money on their Google profile instead.

Usually one of three things. If the site is fundamentally sound and the developer has simply gone quiet, find another developer who works on that platform. There are plenty of good WordPress people around Aylesbury and Oxford, and that is genuinely the cheapest answer.

If the site is beyond saving, rebuild it, and use the opportunity to fix the ownership problem while you are at it. Domain in your own name. An editor you can actually use. The questions worth asking before you hire anybody cover most of what goes wrong the second time round.

And if you cannot tell which of those two situations you are in, ask somebody with no financial interest in the answer. That is what the free health check is for.

Underneath the request there is usually one of three things, and it helps to work out which one you are dealing with.

Sometimes it is money. The site cost two thousand pounds three years ago, and rebuilding feels like admitting that money has gone. Completely understandable, and it is what leads people to spend another eight hundred on patches that never touch the underlying problem.

Sometimes it is dread of the process. Rebuilding means decisions, content, photographs and time nobody has spare. Patching feels like the smaller ask. It generally is not, but it feels like it.

And sometimes it is loyalty. The person who built it was a friend, or a friend's son, and moving on feels like a betrayal. I have a great deal of sympathy for that one and no useful advice about it at all.

Take our particular policy out of it and there is a general point worth keeping.

Any developer who agrees to take on a site they have not seen the inside of, quotes a low fixed price for the work, and promises it will be quick, is either braver than me or has not looked properly. Inherited code is the most common reason small web projects overrun, because the estimate gets made before anybody knows what is actually in there.

So if you are gathering quotes to fix an existing site, the good sign is somebody who asks for admin access before quoting and comes back with a range rather than a single number. The bad sign is an instant fixed price, because that price is a guess, and guesses in this trade get corrected upwards rather than down.

One more exception, since it comes up often enough to be worth naming. If you have a site we did not build and you simply want somebody to keep the lights on, hosting renewed and nothing else changing, we will sometimes take that on. It is a narrow arrangement and we write down precisely what it does and does not cover, because standing still is a much smaller promise than moving forward.

There is a real case against this policy and it deserves stating properly.

A rebuild costs more than a patch. For a business that just needs the contact form working by Friday, being told "we would have to rebuild it" is unhelpful and possibly self serving. I am well aware that a policy of only working on our own builds happens to point every conversation towards a larger invoice, and that a sceptical reader should notice that.

What I can say is that we tell people when they do not need us, we do the health checks for nothing, and we would rather send somebody to a WordPress specialist than take their money for work we would do badly. Whether that holds up is something to judge from how we behave rather than from a blog post arguing that we behave well.

If you have a site causing you grief and want to know whether it is fixable or finished, get in touch. The health check covers speed, mobile behaviour and how you show up in search, and you will get a straight answer either way. Including the answer where the straight answer is that you do not need us at all.