You've Just Inherited a Website You Didn't Build. Now What?

It happens more often than you would think. A developer stops replying. An agency relationship ends badly. Someone leaves the company and takes the knowledge with them. Or you buy a business and the website comes with it.

Now you own an inherited website that works — as far as you can tell — and you have no idea what is inside it. Here is how to find out, in the order that matters.

First: establish access before anything else

This is the single most urgent task, and it is not technical. If the previous developer still controls your domain or hosting, you do not fully own your website — regardless of who paid for it.

Work through this list and confirm you personally hold each one:

• Domain registrar — the account, not just an email saying it renewed. This is the most important item on the page
• Hosting control panel — with billing in your name
• WordPress administrator account
• DNS management, which is sometimes separate from both
• Email hosting, often overlooked until it breaks
• Google Analytics and Search Console ownership
• Premium plugin and theme licences
• Any payment gateway or third-party integration accounts

If a domain is registered under someone else's account and that relationship sours, recovering it ranges from slow and expensive to genuinely impossible.

Where the previous owner is still cooperative, transfer everything now while goodwill lasts. Where they are not, start with the registrar — it is the hardest to recover later.

Second: assume it may already be compromised

Not pessimism. Sites that have been unmanaged for a while frequently are, and the previous owner may not have known either.

Quick checks that cost nothing:

1. Search site:yourdomain.com in Google and look for pages nobody published
2. Open Google Search Console and read the Security Issues report
3. Check the WordPress user list for administrators nobody can account for
4. Visit the site in a private window on mobile data, arriving from a search result rather than typing the address
5. Look in wp-content/uploads for any .php files — there should be none

That fourth test matters because redirect hacks deliberately hide from logged-in administrators and direct visitors. The site looks perfect to you and redirects everyone else.

Third: find out what it is actually built from

Now inventory the software. You are looking for three things: what is outdated, what is abandoned, and what is not legitimate.

Outdated — anything behind on updates, especially with published vulnerabilities.

Abandoned — check each plugin's WordPress.org listing for its last update date. Anything untouched for two years will never be patched again and needs a replacement plan.

Not legitimate — premium plugins with no licence key and no purchase record. This is common on inherited sites and it is a genuine risk. Nulled plugins frequently ship with backdoors already installed.

Also look for custom code. A theme with heavy modifications, or a custom plugin written by the previous developer, is code nobody currently understands. It may be fine. It may also be why updates keep breaking things.

Fourth: check whether anything is being backed up

Ask the question plainly: if this site vanished this afternoon, what would we restore from?

Frequently the answer on an inherited site is nothing, or a backup plugin configured years ago that quietly stopped running. Confirm backups exist, confirm they include the database as well as files, confirm they are stored off the server, and confirm a restore actually works.

Until you have tested a restore, treat the site as having no backup at all.

Fifth: the boring things that cause outages

A short list that catches most inherited-site emergencies:

• Domain expiry date — and whether renewal notices reach someone still employed
• SSL certificate expiry and whether auto-renewal works
• PHP version — unsupported versions stop receiving security patches
• Contact form delivery — submit a test enquiry and confirm it arrives. Broken forms on inherited sites are extremely common and silently expensive
• Where enquiries go — often a former employee's inbox

That last pair is worth doing today. We have seen businesses discover months of lost leads because the form was still emailing someone who left in the spring.

Sixth: change every credential

Once you have access and know what you are dealing with, rotate everything. Not because the previous developer is untrustworthy, but because you cannot verify who else has the passwords, where they were stored, or which laptops they still sit on.

WordPress admins, hosting, FTP, database, and the security keys in wp-config.php — that last one invalidates any sessions still active. Then remove accounts belonging to people no longer involved.

Deciding what to do next

After the audit you will usually land in one of three places.

Sound but neglected. Decent build, just needs updates, backups and monitoring. The common case, and the cheapest.

Working but fragile. Runs on abandoned or nulled components, or custom code nobody understands. Stabilise now, plan a rebuild on your own timeline rather than during an emergency.

Already compromised. Clean it properly before anything else. Hardening or redesigning a compromised site is wasted effort.

If you would rather not do this yourself

Auditing an unfamiliar site is genuinely awkward — you do not know what is normal for it, so you cannot tell what is wrong.

Our WordPress security and error fixing service includes a full audit of an inherited site: what it is built from, whether anything shows signs of tampering, whether it is already compromised, and what needs attention first.

Once it is stable, our managed website plans cover the ongoing updates, backups and monitoring so it does not drift back into the same state.

Send us the web address and tell us what you know about its history. We will tell you what we find, usually the same day.