KeevaathTech

KeevaathTech/Services/Website audit

LENS · Product assessment

Website audit

Six things examined together, returned as a plan ordered by return instead of a list ordered by severity, so the first three items can be done next week.

What this is

An examination of a live website against six things that decide whether it earns its keep: how fast it loads, whether it can be used, whether it can be found, whether it persuades anybody, what state the code is in, and whether it is configured securely.

It returns defects with costs attached and a plan ordered by return, so you can act on the first three items next week instead of admiring a document.

Who buys this

Usually somebody who inherited a site. A marketing lead who cannot get a change made without a fortnight of waiting. A founder whose site was built cheaply three years ago and now costs more to touch than it did to build. An operations lead who has been quoted for a rebuild and wants an independent view on whether a rebuild is the right answer.

The last case is the most common and the most useful. Rebuilding is frequently the wrong answer, and it is always the most expensive one.

What gets examined

Performance

Core Web Vitals measured on real network conditions, not a laboratory score. Render blocking, image weight, font loading, third party scripts and what each one costs you.

Accessibility

An automated pass plus keyboard testing of primary journeys. Enough to tell you the scale of the problem. A full conformance audit is a separate engagement.

Technical search

Indexability, canonicals, titles and descriptions, heading structure, redirects, sitemap, robots directives, structured data and whether Google can actually see what you publish.

Conversion

Where the paths break. Forms that fail silently, calls to action that compete, pages that rank but ask nothing, and measurement that cannot answer which of them works.

Code quality

Optional, and worth including. Dependency and version risk, build and release process, dead code, and how much of the site nobody dares change.

Security configuration

Transport security, response headers, exposed endpoints, form protection, and whether anything sensitive is reachable that should not be.

How we work through it

  1. Inventory before opinion

    What pages exist, what templates they use, what actually receives traffic. A site is usually smaller than its owner thinks and larger than its sitemap says.

  2. Measure, then read

    Automated passes across performance, accessibility and technical search first, so that human attention goes where the numbers say it should.

  3. Operate the primary journeys

    Every path that leads to an enquiry or a sale, completed by hand, on a phone and on a desktop. Most conversion defects are only visible to somebody trying to convert.

  4. Read the deployed code

    Where in scope, we read what is actually serving, not what a repository suggests. Those differ more often than anyone expects.

  5. Group by root cause

    Findings ordered by what fixes them, not by where they appear. One template corrected usually closes dozens of items.

What you receive

Defects, with cost and effort attached

Each one described plainly, located, and given an effort estimate. Ranked by return instead of by severity, because a small fix on a page that receives half your traffic outranks a large fix on a page that receives none.

A sequenced plan

Grouped into what to do this month, this quarter, and what to leave alone. That last category matters. Most audits produce a list nobody finishes, because nothing tells the reader what to ignore.

A keep, fix or rebuild recommendation

With the reasoning and the numbers behind it. If the honest answer is that the site is fine and the problem is elsewhere, that is what the report says.

A walkthrough

An hour with whoever will act on it, so the plan survives contact with your actual constraints.

Where this ends and evaluation begins

An audit examines what exists and tells you what is wrong with it. An evaluation answers a decision, which is whether to keep, rebuild, replace or buy. They are different engagements and they cost differently.

If you already know you are keeping the site and want to know what to fix, this is the right one. If the question is whether to keep it at all, say so on the questionnaire and we will quote the evaluation instead.

What changes the price

Template count instead of page count, the number of primary journeys, whether code review is in scope, and whether the site serves more than one market or language. Multi-market sites carry a real uplift, because the same defect behaves differently in each market and has to be checked in each.

A single market brochure site with eight templates sits at the bottom of the range. An application with thirty templates, code review in scope and three markets sits well above it. One fixed price, quoted once the questionnaire tells us which.

What we need from you

The URL, analytics access if it exists, test credentials for anything behind a login, a note on which journeys you consider primary, and read access to the repository if code review is in scope. If analytics do not exist, that is itself a finding and we work without them.

Questions we are asked

How long does it take?

Three to seven working days of effort, usually delivered within a week and a half. Code review in scope pushes it toward the upper end.

Will you tell us to rebuild?

Only if rebuilding is genuinely the cheaper answer, which is less often than the industry suggests. We do not sell the build, so there is nothing in it for us either way. Several of these audits have concluded that the site was adequate and the real problem was that nobody could publish to it.

We already know the site is slow. Is this worth it?

If speed is your only concern, a performance review on its own is cheaper and we will scope it that way. The audit is worth it when you suspect several things are wrong and do not know which to fix first, which is the usual situation.

Can you audit a site you did not build?

That is the normal case. We audit WordPress, Webflow, Shopify, Next.js, React and plain PHP estates, including ones with no documentation and no original developer available.

Do you fix what you find?

We can, under a separate engagement, and many clients hand the plan to their own team or their existing agency. Selling the audit separately is deliberate, so the findings are not shaped by who profits from the remediation.

What if the site is fine?

Then the report says so and names where the problem actually is, which is usually content, measurement or the process for making changes. That is a useful outcome and it happens.

Send the questionnaire and we will price it.

About fifteen minutes. A fixed price and a start date usually come back within two working days, from the person who would run the engagement, along with an honest read on whether we are the right team for it.

Related