Taking Over a Website You Didn’t Build: The Audit to Run First

Sooner or later, most people who work with websites inherit one. You start a new job and the company site comes with the desk. You buy a small business and the domain is part of the deal. A friend’s developer stops answering e-mails and you are the only person around who knows what FTP stands for.

The tempting first move is cosmetic — new logo, fresh colours, a faster theme. The expensive problems, though, are almost never in the design. They are in the parts nobody looks at: an unsupported CMS version, forty plugins nobody can name, a backup that has never been restored and an admin account belonging to someone who left in 2019.

This is the audit to run before you touch anything, in the order that matters.

Key takeaways

• Identify the platform and its version first — support status decides everything that follows.
• 96% of WordPress ecosystem vulnerabilities are in plugins, not core, so the plugin list is the real risk surface.
• Check for signs of an existing compromise before you make changes; almost half of hacked sites carry at least one backdoor.
• A backup you have never restored is not a backup.
• Decide who owns updates from now on. “Everyone” means nobody.

1. Find out what the site actually runs on

Start with the platform, because it determines the rest of the checklist. WordPress still dominates: as of September 2026 it powers 40.3% of all websites and 58.8% of the CMS market, with Shopify at 5.4%, Wix at 4.2%, Squarespace at 2.4% and Joomla at 1.1% of all sites (W3Techs).

That last number is worth pausing on. Joomla’s share is small, but the installed base is old — a lot of those sites were built between 2012 and 2016, which is exactly the profile that ages badly.

Where to look:

• WordPress: Dashboard → Updates shows the core version. Without admin access, /wp-json/ or the generator meta tag usually gives it away.
• Joomla: System → System Information in the administrator, or the presence of /administrator/ and /media/system/.
• Hosted builders (Wix, Squarespace, Shopify): the platform handles the updates, so your audit shifts to accounts, billing and exports instead.

2. Check whether that version is still supported

An unsupported CMS is not “old but working”. It is a public list of known holes with no patches coming.

For Joomla, the dates are unusually clear-cut (endoflife.date):

If the site you inherited runs Joomla 3, treat everything else in this checklist as secondary. Every publicly known vulnerability in that branch has had three years of exploit tooling built around it.

WordPress is friendlier here — core auto-updates for minor releases have been on by default for years — but that only covers core.

3. Inventory the plugins and extensions

This is where the actual risk lives. According to Patchstack’s State of WordPress Security report, 7,966 new vulnerabilities were published in the WordPress ecosystem during 2024 — roughly 22 per day. Of those, 96% were in plugins and only 4% in themes, with fewer than seven in core. Perhaps the most uncomfortable figure: 33% were not fixed by the time they were publicly disclosed, and 43% required no authentication at all to exploit.

Go through the list and sort every item into one of four buckets:

• Actively used and maintained — keep and update.
• Used, but last updated years ago — find a replacement now, not later.
• Installed but inactive — delete. Deactivated does not mean unreachable; the files are still on the server.
• Nobody knows what it does — investigate before you remove it, especially on Joomla, where a template override can quietly depend on an extension.

If the site has a staging copy, this is exactly what it is for. If it does not, make one — the safe way to clone a WordPress site takes an afternoon and saves you from testing on live traffic.

4. Audit who has access

Handovers are messy, and access lists are where the mess accumulates. Write down every account for:

• the CMS administration (and their roles — not everyone needs to be an administrator),
• hosting control panel, FTP/SFTP and database,
• the domain registrar and DNS,
• e-mail, analytics, Search Console, payment gateway and any marketing tools.

Remove what you do not recognise, rotate the rest and turn on two-factor authentication wherever it exists. One note of caution: if you find an admin account you cannot explain, do not simply delete it and move on — it may be evidence rather than leftover clutter. More on that in the next step.

5. Find the backups — then restore one

Ask three questions: where are the backups, how far back do they go, and has anyone ever restored one?

Host-level backups are usually thinner than people assume. Retention on shared hosting is often measured in days, not months, and on entry-level plans a weekly backup may simply overwrite the previous one. If a problem goes unnoticed for three weeks — which is common — the host’s copy is worthless by the time you reach for it.

So: keep your own copy, off the hosting account, and restore it to a staging site once. An untested backup is a belief, not a safety net.

6. Check whether the site is already compromised

Run this step before you change anything, because a redesign on top of a compromised site just carries the problem forward.

The base rates are sobering. In Sucuri’s 2023 hacked website report, 49.21% of compromised sites contained at least one backdoor, 39.1% of CMS applications were out of date at the point of infection, and 20.30% of cleaned sites were carrying some form of SEO spam.

Practical checks that take ten minutes:

• Google Search Console → Security Issues. Anything here is not a maybe.
• Search your own site with site:yourdomain.com and look for pages you did not create — pharmacy, casino or replica-goods listings are the classics.
• Look in the uploads directory for PHP files. Images do not execute code; PHP in an image folder is a strong signal.
• Check admin users for accounts created outside business hours.
• Open the site on mobile from a different network. Some injected redirects only fire for mobile visitors arriving from search.

If any of these hit, the job stops being maintenance and becomes incident response: preserve a forensic copy first, then find the entry point, then clean. That order matters, and it is why cleaning an infected Joomla site is a specialist job rather than a plugin you install — deleting the malicious file without closing the hole simply restarts the clock.

7. Confirm the domain, DNS and e-mail are yours

The website is replaceable. The domain, in most cases, is not.

Verify that the domain is registered to your organisation rather than to a former developer’s account, check the expiry date, enable auto-renew and put the renewal in a calendar you actually read. While you are in DNS, confirm the mail records (SPF, DKIM, DMARC) point where you think they do — inherited sites frequently send transactional mail through a service nobody has paid for in years.

It is also worth knowing what happens when hosting expires before you find out experimentally.

8. Decide: maintain, rebuild or migrate

By this point you have enough to make the call honestly.

• Maintain when the platform is supported, the extension list is short and the content structure works. Cheapest option by far.
• Rebuild when the CMS is end-of-life, the extensions are abandoned, or the design is entangled with hacked-together code. A Joomla 3 site is usually here.
• Migrate to a simpler platform when nobody in the organisation will ever maintain a self-hosted CMS. That is a legitimate answer, not a defeat.

Whatever you choose, clean first and redesign second. Rebuilding on top of an infected database means importing the infection into the new site.

9. Give the updates an owner

Almost every inherited-website disaster traces back to the same root cause: after the handover, nobody owned the boring work. Updates, backups, monitoring and a quarterly look at who has access are not projects; they are a routine.

Write down who does it, how often, and what happens when something breaks at 9pm on a Friday. If the answer is “nobody, really”, buy the routine instead — an ongoing maintenance plan costs a fraction of one emergency cleanup, and the difference between the two is mostly a matter of who notices the problem first.

FAQ

How do I find out which CMS a site uses without admin access?

Check the page source for a generator meta tag, look for tell-tale paths (/wp-content/, /administrator/) or use any CMS-detection tool. If nothing matches, it may be a static site or a custom build — which changes the maintenance question entirely.

Is an old website dangerous even if it has almost no traffic?

Yes, because attacks on CMS sites are automated. Scanners crawl millions of domains looking for version fingerprints; they neither know nor care how many visitors you get.

Should I update everything immediately after taking over?

Update, yes — but take a full backup first, do it on a staging copy where possible, and go one major component at a time. On a site that has not been touched for years, an update can break a template override that nobody documented.

The previous developer will not hand over the accounts. What now?

Domain ownership can usually be reclaimed through the registrar with proof of organisation identity. Hosting accounts are harder, which is a good argument for rebuilding on infrastructure you control rather than negotiating.

Final thought

Inheriting a website is mostly an exercise in finding out what you actually own. Spend the first day on versions, plugins, access and backups instead of colours, and you will know within hours whether you are looking at a tidy handover or a rescue.

And if the audit turns up something worse than neglect, resist the urge to start deleting. The evidence you preserve in the first ten minutes is what tells you whether the problem is over.