A website audit and what it finds

The site works, orders come in, nobody complains. In that situation the question of whether it is time for a check-up sounds odd, and that is exactly why checks usually happen after an incident rather than before one.

The problem is that a site ages invisibly. It does not break in one day; it accumulates small discrepancies, each of which means nothing on its own.

Why check a site that works

An audit is not always needed. There are moments when it pays for itself immediately, and moments when the money spent on it is wasted.

• The site is more than three years old. In that time the search engine’s requirements, the software versions and the business itself have all changed.
• The contractor has changed. A new team needs to understand what it has inherited.
• Traffic dropped with no visible cause. Advertising has not changed, yet there are fewer inquiries.
• A large piece of work is planned. It is cheaper to establish the current state before adding anything new.
• The site is being handed over internally. Whoever looked after it is leaving, and what exists has to be recorded.

If none of these applies and the site was built last year, an audit can wait.

There is also the opposite situation, where the check comes too late. The owner notices fewer inquiries, waits a quarter deciding it is seasonality, then waits another. Within six months the problem has usually snowballed: the search engine has reassessed the site, some pages have dropped out of the index and competitors have taken your place in the rankings. Fixing that takes longer and costs more than it would have at the start.

What accumulates over the years

Plugins installed and forgotten

On one of the sites we audited, twenty-eight extensions had been installed over four years, and only twelve were in use. The rest either duplicate one another or solved a problem that disappeared long ago.

Disabled extensions carry weight too. They are not running, but they remain on disk, and an unpatched vulnerability in a file sitting in a folder can still be exploited whether or not the plugin is switched on.

A separate category is extensions that are no longer maintained. The author stopped supporting them and the site still depends on them. That is no reason to rip everything out at once, but you need to know about these dependencies.

A database swollen with logs and drafts

A database grows even when no products or pages are added.

• Drafts and page revisions. Every save creates a copy, and thousands accumulate over the years.
• Extension logs. Some plugins write their own history into the database and never clean it.
• Temporary records. Created for caching and meant to disappear by themselves, which they often do not.
• Data from removed extensions. The plugin went, its tables stayed.
• Records from old integrations. An exchange with a service nobody uses anymore.

On a large catalog this directly affects the speed of the admin area and the time it takes to build a page. Bloated tables without the right indexes slow queries down, and a complex page runs dozens of queries.

Cleaning a database is not a dangerous operation if it is done properly: a backup first, then deletion based on specific criteria, then a check. What is dangerous is the opposite, leaving it untouched for years and then deciding to clear everything at once without distinction.

An outdated PHP version

The PHP version a site runs on eventually stops receiving security fixes. The site keeps working perfectly well, which is exactly why the question gets postponed.

The difficulty is not the update itself but the fact that some older extensions are not compatible with a newer version. So a compatibility check is a separate item in an audit, and the outcome is not “update” but a list of what will have to be replaced before updating.

Access nobody remembers

This is the most awkward part, because it is not technical.

The real risk is that after any incident it becomes impossible to work out where it came from.

The other side of the same problem shows up when access is urgently needed. The domain is registered to a former employee, the mail is tied to their personal address, and they left long ago and do not reply. These situations can be resolved, but the registrar’s recovery procedure takes weeks, and going through it under pressure is far less pleasant than doing it calmly.

Backups that do not really exist

Everyone is asked about backups, and the answer is almost always yes. Follow-up questions change the picture.

• Where they are kept. A copy on the same server is not a backup.
• What exactly is saved. Files without the database, or the database without files, are useless.
• How fresh they are. A month-old backup is of almost no use to an online store.
• Whether a restore has been tried. Usually not.
• How long a restore takes. Almost nobody knows this figure.

The practical part of an audit comes down to one step. Take a fresh copy and deploy it on a test environment. The result is often unexpected.

Three findings come up most often. Backups were made by a plugin that was switched off two years ago, and no new archives have appeared since. Or the archives exist but contain no database, because the setup only copied files. Or everything is there, but a restore takes six hours, which nobody suspected.

Traces of previous contractors in the code

When three different teams have worked on a site over the years, layers remain in the code.

The most common finding is duplication: the same task solved twice in different ways, both solutions running at once and occasionally conflicting. Then come edits made directly inside extension files. They work only until the next update, which overwrites the files and the edits with them, and the problem they fixed comes back.

Third-party code embedded in the site is checked separately. That is not always the result of a compromise; sometimes it is the remains of somebody else’s analytics or affiliate scripts connected once and forgotten. Every such script is an extra call to somebody else’s server while a page loads, and if that server is slow or unavailable, your site waits along with the visitor.

Another finding typical of sites with a complicated history is several analytics systems at once. Two or three different tracking codes installed by different people in different years. Their numbers do not match, it is unclear which to trust, and in the end nobody looks at any of them.

Forms, analytics and the path of an inquiry

The technical part shows the state of the site, but what the owner cares about is whether inquiries arrive. That is checked separately, and it is where the most expensive mistakes are found.

• The form sends an email. And it does not land in junk.
• The recipient address is current. Often it still belongs to somebody who left.
• The inquiry is stored somewhere. Not only in an email that can be deleted by accident.
• The traffic source is passed along. Without it, no campaign can be evaluated.
• The event is recorded in analytics. So you see conversions rather than only visits.
• It works on a phone. Checked on a real device.

A test inquiry sent from a phone in the client’s presence settles most questions in five minutes. Sometimes it simply does not arrive, and it turns out that has been the case for months.

What Google already shows about your site

Some of the answers are already sitting in Google Search Console, and owners rarely look there.

• How many pages are in the index. If there are several times more than real pages, duplicates are being generated somewhere.
• Which pages are excluded and why. Needed sections often turn up on that list.
• Which queries the site appears for. Sometimes not the ones anyone expected.
• Crawl errors. Broken links, unreachable pages, slow responses.
• The state of the mobile version. For most sites that is the main source of traffic.

Speed is examined separately; the usual causes of delays are described in our article on why a website loads slowly. Most of what is found is fixed as part of project support and development, which is why an audit usually precedes a maintenance agreement rather than the other way round.

What you check by eye rather than with a tool

Some findings are invisible to every tool, and they are usually the expensive ones.

Open the site on a phone and try to do the thing it exists for. Find a price. Find the delivery terms. Send an inquiry. Call in one tap. If any of those steps takes effort, that is the step where the visitor leaves.

Read the text on the main pages as if you knew nothing about the company. It often turns out that a service page never answers what is included and what it costs, while describing an individual approach at length.

Look at what the search results say for the company name. The search engine assembles the title and the description itself, sometimes from the site settings and sometimes from the content of the page, so judge by the results rather than by the settings.

Open your site and two competitors’ sites in adjacent tabs and compare them. That tells you more than any list of technical remarks, because that is exactly how a visitor chooses.

What the report looks like

A report should be something you can work with, not something you admire.

• A list of findings with explanations. What was found, what it threatens, how urgent it is.
• Grouping by urgency. Critical, planned, desirable.
• An estimate of the work. How many hours each item will take.
• What you can do yourself. Some items do not need a contractor.
• What is not worth doing. Sometimes the right answer is to leave it as it is.

The last point is what separates a useful audit from a list of complaints. Not every finding requires a fix, and an honest report says so plainly.

The format matters too. A forty-page report from an automated tool looks impressive and gives you nothing: hundreds of identical remarks with no separation between important and trivial. A working report is shorter and built around consequences rather than technical parameters: not “attribute missing” but “because of this the page does not appear for that query”.

What is fixed at once and what goes into a plan

What gets fixed at once is anything that creates risk or is already costing money.

Critical means unsecured access, missing backups, unpatched vulnerabilities and pages the search engine cannot see because of a technical fault. That work does not wait for a quarterly budget approval.

Planned means version upgrades, database cleaning, removing surplus extensions and work on speed. These are done on a schedule, with a backup before each step.

Desirable means what would improve the site but is not urgent: reviewing the structure, refreshing text, improving forms. This is also where the question of whether the site needs replacing altogether belongs, and it is covered in our article on when a website needs a redesign.

How long it takes and what it costs

An audit of a company site takes from a few hours to a day. A shop with integrations takes longer, because data exchanges are examined as well.

The search part of the check, meaning indexing, duplicates, redirects, the sitemap and speed, is done as part of our search engine optimization service and charged as a one-off, from $200. Plugins, hosting settings, backups, access rights and the code left by previous contractors are checked as part of project support and development. The initial review and a rough estimate are free of charge. The full check is estimated in hours up front and, depending on scope, counts against the hours of a support plan or is billed hourly. Fixes afterwards are either included in regular maintenance or done as one-off tasks.

How an audit differs from handover acceptance

Acceptance checks whether what was ordered was delivered, and happens once when a new site is handed over. What to check is covered in our article on the website handover checklist.

An audit checks the state of a site that has been running for a long time, and looks not for unfulfilled promises but for accumulated consequences. The lists of items partly overlap, but the questions differ: there it is “Was everything done?”, here it is “What has degraded since?”.

Conclusions

An audit does not make a site better by itself. It gives you a map: what exists, which parts of it pose a threat, what is costing money right now and in which order to fix things.

The greatest value of such a check is the uncertainty it removes. The owner stops guessing why traffic fell and whether it is safe to update the system, and starts making decisions based on facts.

If you are not sure what state your site is in, send us its address and access to Google Search Console if you have it. We will go through the points above and come back with a report where the findings are separated by urgency and estimated in hours. If it turns out the site is in reasonable shape and nothing is urgent, we will say so and propose a maintenance schedule instead of a list of work.