Website analysis

Most defects on a site are invisible from the homepage — the owner opens it every day and is sure everything is fine.

Faults pile up unnoticed. A product is removed, but the link to it stays in the menu and people land on an empty “not found” page. The mailbox is changed, and for three months the enquiry form sends nothing anywhere. One more module is installed, and the catalogue layout falls apart on phones.

We walk through the site twice: as an ordinary visitor and as a search robot. We check every link, open the forms and send a test enquiry, and view the pages on a phone rather than only on a desktop. We also look for duplicates — one product reachable at three different addresses, so search cannot tell which one to show.

• broken links and “not found” pages
• forms whose messages never reach the mailbox
• the same page duplicated at different addresses
• broken layout on phones and tablets

The form is the most common reason we are called in. It looks like it works: the visitor clicks “Send”, sees “Thank you” — and the message arrives nowhere. Owners usually find out by accident, when a client calls back and asks why nobody replied.

The simplest check to run once a month: send an enquiry from your own site as a normal customer and see whether the email arrives. Five minutes — and it saves you from months of silence.

What matters is not that the site is “slow”, but which exact file or module eats those seconds — otherwise there is nothing to fix.

We do not judge speed by eye. The page is broken down into parts: how much the images weigh, how long the server takes to answer, which scripts load before the text. That is how it becomes clear that three of the four seconds of waiting are a dozen photos of several megabytes each, uploaded straight from the camera.

The causes almost always fall into three groups. Heavy images — the most common and the cheapest to fix. Extra scripts — when a slider, a map and a chat widget load on every page although they are needed on one. And hosting — the place where the site files live, like a rented flat: on a cheap plan your site queues up behind a hundred neighbours.

• the weight and format of the images on a page
• how many modules and scripts load every single time
• server response time and the hosting plan
• whether caching is on — ready-made copies of pages

A typical mistake is to pay for a more expensive hosting plan straight away. If the drag is a gallery of thirty photos at six megabytes each, a stronger server will deliver the same megabytes slightly faster, but a visitor on mobile internet still gives up and goes back to search.

Ask for figures before and after. “It feels faster” is an impression; “the homepage took 4.2 seconds and now takes 1.6” is a result you can see in the report and check yourself.

A page that is not in the search engine’s database does not exist for your customer, however good that page is.

Google first has to find a page and add it to its list — this is called indexing. Only then can the page show up in search results. It happens like this: a shop has 400 products and only 120 made it into search. The rest are on the site, you can see them — the buyer cannot.

The reasons are almost always technical: the page was accidentally closed off from search by a service file, no link on the site points to it, its description is empty, or it repeats another page almost word for word. We compare the list of pages on the site with what actually reached the index and explain the reason behind every gap. The search engines’ own reports we go through separately, in the technical analysis.

• how many pages the site has and how many are in search
• which pages are excluded and for what reason
• whether the sitemap and the robots file are correct
• which queries already show your site to people

Visibility and rankings are two different things. First the page has to be in the index, and only then does it make sense to discuss its position. Promoting something search cannot see means paying into a void: the budget goes out and the page never appears in the results.

If the owner panel (Google Search Console) is not connected to your site yet, connect it. It is free and it tells you by itself which pages search rejected and why.

Sites are not hacked by name: robots crawl the web at random, looking for an old version with a known hole in it.

So “who would bother with my small site” is not a defence. A hacked site is rarely damaged for show. More often someone quietly plants foreign pages on it, or arranges for visitors on phones to be redirected elsewhere. The owner opens the usual homepage and notices nothing until Google starts warning people that the site is unsafe.

We look at how open the site is to that: how long ago the management system and its add-ons were updated, whether former contractors still have access, whether the administrator uses a simple password, whether the security certificate — the little padlock next to the address — is valid. Backups are checked separately: whether they exist at all, how often they are made and where they are kept.

• versions of the management system and its add-ons
• who has access to the admin panel and the hosting
• whether the security certificate is still valid
• whether backups exist and are actually usable

The nastiest discovery is usually not a virus but the backups. They are supposedly made every night — yet they sit on the same server as the site, or have never once been tested by restoring them. When the moment comes, there turns out to be nothing to restore from.

The analysis shows the state of things and lists the threats. The treatment itself — cleaning out viruses, changing access, closing the holes — is separate work, and we say up front how much of it there is.

A customer never judges your site on its own — they open four tabs in a row and stay on the clearest one.

That is why looking only at your own site tells you little. We take several companies that sit next to you in search results and go through them as a buyer would: is there a price, are the delivery terms visible, how many steps lead to an enquiry, what the product page actually says. This is often where the answer to “why do they get orders while people just look at us and leave” is found.

We compare three things. Structure: they have a separate page for every service, you have everything crammed into one — which is why search shows them. Content: they show prices, photos of their work and lead times, you offer an “individual approach”. Technology: speed, convenience on a phone, how many taps it takes to reach the order button.

• how many pages competitors have and what each is for
• what their pages show that yours do not
• which queries show them and leave you out
• their speed and mobile usability next to yours

The point is not to copy someone else’s site: a copy always loses to the original, because it repeats the original’s mistakes too. The point is to see your own gaps and work out what really sets you apart, so it can be said in plain view instead of being buried at the bottom of the “About us” page.

To be honest about the limits: nobody sees another business from the inside — how many enquiries a competitor gets is unknown to us. We compare only what is visible from outside, and traffic estimates for them are always approximate.

A report is useful when every item in it can be turned into a task for a developer — with no translator from technical language needed.

Automated tools produce a sheet with hundreds of “errors”, half of which mean nothing while the rest are written in language only a programmer follows. Such a file is usually opened once and never again. We write it differently: what is wrong, where exactly it was found, what harm it does and what to do about it.

Items are ordered by importance, not by the section of the audit they came from. First what is directly costing you enquiries: a broken form, pages closed off from search, four seconds of loading. Then what brings growth gradually. And we mark separately what you can do yourself in half an hour and what needs a developer.

• the problem described in plain words
• the address of the page where it was found
• exactly how it holds the site back
• what to do about it and how urgent it is

If you have your own developer, the report goes straight to them as a ready list of tasks, with no extra explanation needed. If you do not, we can take the fixes on ourselves: analysis, development and promotion are in one team here, so between finding a problem and fixing it there is no middleman to misunderstand it.

Hold any audit, whoever wrote it, to one requirement: after reading it you should know what to start with tomorrow. If you do not, it is not a report — it is a dump from a program.