What we check before taking over an existing Joomla website
Websites often outlive the working relationship with whoever built them. The developer moved on, the agency closed, or the person who knew how everything fits together left the company. What remains is a working site and very little knowledge about it.
Before agreeing to maintain a site like that, we review it. Partly this protects us from promising routine care for something that is about to fall over. Mostly it protects the owner, who should know what they have before paying anyone a monthly fee for it. This is what the review covers.
Versions and support status
The Joomla version, the PHP version, the database version, and whether each is still supported. A site on Joomla 5 or 6 with a supported PHP version can go straight into routine maintenance. A site on Joomla 3 or 4 cannot be kept safe by updates, because there are none. It needs an upgrade project first, and saying so at the start is better than discovering it in month three.
Every extension, and who owns the licence
A full list of installed components, modules, plugins and templates, with three questions for each. Is it used? Is it maintained? Is it paid for, and by whom?
The last question causes more trouble than any technical issue. Commercial extensions only update with an active subscription, and that subscription often belongs to the previous developer's account. The site shows "update available" forever and nobody can install it. These licences have to be bought again, and they are best bought in the owner's own name, so the next handover, including one away from us, is easier than this one.
Unused extensions are removed. Every installed extension is code that has to be kept up to date, whether or not the site uses it.
Backups that have been restored at least once
It is not enough that a backup extension is installed. We want to know when the last backup ran, where the file is stored, how long files are kept, and whether anyone has ever restored one.
A backup stored only on the same server as the site disappears together with the site. A backup that has never been restored is an assumption. The only real test is to restore one to a separate location. A first restore can fail for dull reasons, such as an incomplete archive, a database dump that stops halfway, or a folder that was excluded from the backup years ago and forgotten.
Who has access to what
The list of Super Users and administrator accounts usually contains people who no longer work with the site: former employees, the previous agency, a freelancer from 2019. Each is an active key to the site. They are removed or downgraded, with the owner's agreement. For the accounts that stay, we recommend switching on multi-factor authentication, which is part of Joomla from version 4.2.
Then the accounts around the site: hosting panel, SFTP, the domain registrar and DNS. The registrar matters most. If the domain is registered in a former developer's name, the owner does not control their own address, and sorting that out while relations are still friendly is far easier than doing it during a dispute.
Whether email arrives
Contact forms that send into nothing are common, and nobody notices because the absence of enquiries looks like a quiet month. We submit every form and follow the message to the inbox. We check how the site sends mail, through the server's default mail function or through a proper SMTP account, and whether the domain's SPF and DKIM records allow it. Form notifications sent from the visitor's own address are a typical reason for mail landing in spam.
Scheduled jobs
Cron jobs in the hosting account and Joomla's own scheduled tasks. Some are needed, such as backups or search indexing. Some point at scripts that no longer exist and fail silently every night. A few were never meant to be there. Each one should have a known purpose.
Changes made outside the rules
Joomla allows the output of any page to be customised safely through template overrides. It does not stop anyone from editing core files or extension files directly, and on older sites someone usually has. Those edits vanish at the next update, which is how a routine update turns into "the site looks different and the booking form is gone".
We compare the core files against a clean copy of the same Joomla version to find such edits, and note every template override, because overrides copied from an old Joomla version are a common source of errors after an update.
Leftovers
Old backup archives in the web folder, an installer script from a past migration, a file that prints the server's PHP configuration, a staging copy of the site in a subfolder that search engines have indexed. Each is a small security or SEO problem, and together they say something about how the site has been looked after.
Errors already happening
We read the PHP error log and Joomla's logs before changing anything. A site can look fine and still log a few hundred errors a day. Knowing what was already broken matters for a plain commercial reason: what was broken before we arrived is repair work, and what breaks under our care is ours to deal with.
Why we do not click "Update all"
A maintenance routine that consists of pressing the update button on a live site works until the day it does not, and then the site is down with no plan. Updates are applied after a backup, in a sensible order, and for sites where an outage is expensive they are tried on a staging copy first. The review tells us which kind of site we are dealing with.
The result of all this is a short written list: what is fine, what needs repair before routine care makes sense, and what can wait. Repairs are quoted separately from the care plan, so the monthly fee covers a site in a known state. The review is available on its own as a Website Health Check, and the ongoing part is described on our website care page.