EnterraHost
A website audit is easy to run and hard to read, because it answers six questions at once and prints them with equal confidence. The website audit tool is the one this article is about, and reading it well comes down to knowing which of its numbers can change a decision.
The audit has two halves. The left tab is a real test of one page from a region and a connection speed you choose. The right tab is a crawl of up to twenty pages, which is where the structural findings live. They measure different things and neither one is a ranking.
What the scores are actually made of
Performance is the only score built from measurements a browser took on the page. It comes from the Core Web Vitals and a few timings around them, which is why a perfect score and a slow-feeling page can both be true. The number describes one load, on one connection, from one place.
Security is a count of response headers and certificate facts. It says nothing about the application behind the page, and a site with every header present can still be running an unpatched plugin.
The SEO score is EnterraMon Pro’s own scoring of what that page declared, run through the same scoring code the paid product uses. It reads the title, the description, the heading structure, structured data, the robots file and the sitemap. It is a summary of declarations, not a prediction of position.
Accessibility comes from axe-core, which runs a fixed set of rules against the rendered page. It finds contrast failures, missing labels and headings that skip a level. It does not find whether the reading order makes sense, and passing it is not the same as being usable.
The numbers that decide something
Three timings are worth remembering, and the thresholds come from Google’s Core Web Vitals rather than from us.
| Measurement | Good | What it is |
|---|---|---|
| Largest Contentful Paint | 2.5 seconds or less | When the main content finished arriving |
| Cumulative Layout Shift | 0.1 or less | How much the page moved while loading |
| Interaction to Next Paint | 200 milliseconds or less | How long the page takes to respond to a tap |
| Time to first byte | 800 milliseconds or less | The server and network before any markup arrives |
Time to first byte is not a Core Web Vital, but it is the one to look at first when everything else is bad. No amount of front-end work recovers from four seconds of it. The ping test at five regions and the server check separate the network from the server.
What the weight figures mean
A total weight is not a decision. The split is. This is a real audit of our own homepage, and the interesting number is not the 515 kilobytes, it is that 30 per cent of it is CSS while JavaScript is 18 per cent.
Read the third card as carefully as the first. An asset that is cacheable is fetched once and reused, and a page that is not cacheable is fetched in full on every visit. The two numbers in that card describe a page whose assets are well behaved and whose document is not.
The waterfall, and the one marker worth learning
The waterfall answers a question no score can, which is what the page waited for. Each row is one request, each bar starts when that request started and is as wide as it took.
The number in its own column beside a row is the type of file. A 3 beside a row means the request was served by somebody else, which is the distinction that explains most slow pages, because third-party code is the part of a page you did not write and cannot cache.
Findings are ranked by what they cost
The findings list sorts by severity and then by the points the rule can recover, so a high finding at the top is not automatically the one to fix. A missing security header costs points on every page and takes ten minutes. A title that reads badly costs a click in a search result and takes longer to fix properly.
Some findings are informational. A published security.txt is not a fault, and the audit marks it as information because that is what it is. Treat the list as a queue ordered by cost and benefit rather than by the label on each row.
The second tab is a different report
The EnterraSEO tab crawls up to twenty pages and reports what a search engine reads. It carries its own score, run through the same scoring code the paid product uses, and a coverage row that is a count of pages rather than a judgement.
Coverage is the part to read slowly. A title written once for every page is still a title on every page, and a hundred per cent here means each page has one, not that each one is any good. The findings below the rings are where quality is judged.
The crawl also says which business type it read the site as, because that decision changes which words count. A hosting company and a law firm have different commercial vocabulary, and a rule that looks for a product term has to know which words those are.
What the audit cannot see
It reads one page, once. It cannot see how a page behaves on a real phone on a train, whether the content answers the question it ranks for, or what happened last month. There is no history, so a score that dropped yesterday looks the same as one that has been low for a year.
That is a limit of a single test rather than a fault in it, and it is why the report says so in plain words at the end. EnterraMon Pro keeps the runs, and the difference between one number and a line of them is the difference between a photograph and a diagnosis.
The order to fix things in
Start with what makes every other number meaningless. A certificate that expires this month, a page that returns an error to one region, or a server that takes three seconds to answer all outrank a contrast failure.
Then the largest content. If the main image or heading arrives after four seconds, fixing it moves the score more than any other single change.
Then what repeats across pages. The crawl tab groups findings that appear sitewide, and one template fix is worth more than twenty page edits. The second tab also carries the SEO score for each page it read, which is how you find the pages that were missed while the homepage was being polished.
Everything else is maintenance. Run the audit again after a change, because a report describes a moment and the moment after a fix is the only one that tells you whether it worked.