Is a scanner score already an audit?

No. A score without an operation, evidence, and a business effect is only decoration. A useful audit names the request path, the measured seconds, the release path, and the change you should not make yet. Tool names do not replace that list.

Do we need to give production access for an audit?

You need enough access to read logs and to test safely somewhere that is not live. A password pasted into chat is not a process. If the only database you can inspect is the live one, say that clearly and take a copy before you experiment. Keep customer values out of the report.

The vendor wants a rewrite before any checks. What should we ask for?

Ask for three things first: the operation, the seconds, and the request path. Messy code that runs one indexed query is maintenance, not today's incident. A rewrite can be a later project, but not a substitute for evidence.

Which numbers are worth putting into the audit note?

Use the seconds for one operation people already wait on, measured on this system before and after a change. Add rows examined versus rows sent, or response size, only when those numbers explain the wait. A benchmark from another platform is not evidence for your case.

What should we send if we want a second opinion?

Send the operation, the measured seconds, and what one test submission did. Do not send raw logs full of customer values, and do not send passwords. If you do not have the seconds yet, send the page, the symptom, and which log nobody can open.

Site technical audit: what to check first and what not to conclude yet

A technical audit is a short list of checks with evidence. Each check ties to something the business already feels: a lost request, a slow page, a release nobody can repeat, or rows from the wrong customer. A PDF full of tool names is not that list.

People ask for an audit when trust is already low. The site feels slow. Leads are "somewhere." Last month's release surprised the team. Or a new vendor wants a rewrite before they touch the code. A useful audit does not start with a score. It starts with one operation. Name it. Measure it. Read the failure that operation already produces. Then recommend only the change that this evidence supports.

These are the checks I run before I talk about a rewrite. They are plain checks. They also move the business conversation, because each one answers a question a non-developer already has. Skip the performance. If a check has no evidence, it is not a finding. If a finding has no business effect, it can wait.

1. One request path, walked end to end

Pick the form, booking, or checkout the business depends on. Submit it once with a value you can search for later. Record whether thank you appeared on the site, where a staff member looks the next morning, and whether your value is there. This is not a UX review. This is the difference between ad spend and a real conversation the team can have.

Write the destination in concrete words: a mailbox, a database row, a CRM card, a calendar entry. "The system" is not a destination. If a person still copies fields by hand, that manual copy is part of the path, and the audit should say so. The common failure points are already covered in why the lead never arrives and what breaks between a form and a CRM. An audit that never walks this path can easily recommend redesigning a page that was already saving the request.

2. One slow operation, measured in seconds

Ask which page or job people already wait on. Time it yourself. Put the seconds next to the URL or the job name. A vague "the site is slow" leads to a vague rewrite. A number gives you a suspect: one query, one loop of queries, one response the browser must finish reading before the person can continue, or one lock.

Open the slow log for that time window if you have it. Group statements by text. Compare rows examined with rows sent. Count repeats. A loop under the log threshold can still dominate the wait, so a quiet log does not prove a fast page. The reading order is in how to read the slow log before you refactor. Do not quote a speedup from another platform. A number from one operation does not transfer. Measure this operation here, before and after, on this system.

If a process keeps growing until a restart is the only fix, that is a different check from a slow query. Record memory size before the action, at the peak, and after. Buying more RAM only hides the issue until the same hour tomorrow. The pass is what to check before you buy memory. An audit that recommends RAM from a hunch has not done this work.

3. Whether a change can be tested before customers see it

Find out how code reaches the live site. Note the branch, command, or pipeline, who can run it, and whether a second environment exists. If production is the only place where a change can be tried, say that on the first page of the audit. That finding should delay every feature proposal. Editing live because there is nowhere else to test is how a small fix turns into an incident. The decision, for the people who will feel the result, is in do not patch production because a test environment is missing.

Backups belong in the same section. A backup you have never restored is only a hope. Note whether a restore has been done, when it happened, and how long it took. If nobody knows, the finding is "not proved," not "we are fine." Secrets belong here too. A password in the repository, in a chat, or in a dump on a laptop is a finding even when the page is fast. The audit should name the system and the fact. It should not paste the secret into the report.

If one product serves several customers, take two accounts and look for a leak: a report, a search, a night job, an export. One row from the wrong customer is a business incident, not a style issue. The usual starting point is covered in where data isolation breaks. An audit that profiles a single-tenant demo and skips this check can approve a report that mixes clients the week the second customer arrives.

Read the error log for the last week beside that. Group repeated failures. A job that has failed every night is not a footnote under "code quality." It is mail that did not send, a card that was not created, or a file the team rebuilds by hand every morning. Tie the repeated line to the operation. Leave one-off noise for later.

5. What the audit should refuse to conclude

Refuse "rewrite the site" as line one. Messy code that runs one indexed query is maintenance. It is not today's incident. A rewrite is a later project with its own reason, after the request path, the seconds, and the release path are written down.

Refuse a queue or a cache as the first move against a statement you have not read. A background job that runs the same loop still examines the same rows. The person sees a "processing" state instead of a spinner. The cost only moved. Cache the result after you know the result is worth storing. A queue belongs when the work should leave the request and a retry must not repeat a side effect. That is a different decision. That line is in when a queue belongs beside the application.

Refuse a pile of dependency warnings with no link to a real failure. Old packages matter when they block a fix, when they are exposed, or when you are about to change the area they sit in. A list of forty upgrades is not an audit. It is a backlog pretending to be a diagnosis.

6. What the result should look like

The note a business can use is short. For each finding, write the operation, the evidence, the effect (lost request, wait, wrong customer's rows, release risk), and the next change. Order the list by what to do first, not by which tool looked impressive. One operation, before and after, beats a dashboard.

The request path, walked once, with the destination named.
Seconds for the slow operation, plus the statement or the response size if that is the cause.
How a change is released, and whether a non-live place exists.
Backup restore: done, or not proved.
Secrets: where they leaked, without copying them into the note.
If customers share the product, the two-account check.
Repeated errors from the last week, tied to an operation.
What you will not rewrite until those lines exist.

Hand the note to the people who feel the effect, in words they can repeat. Keep customer values out of the examples. Strip literals from any SQL you attach. An audit that leaks the data it was supposed to protect has failed, even if the findings were correct.

When a second pair of eyes is the point

A team that can open the logs can do this list on its own. Ask for a second look when the log sits on a server nobody can read, when the only database you can explain against is the live one, or when a vendor jumps straight to a rewrite without the seconds and the request path. Send the operation, the seconds, and what one test submission did. Do not send a raw log full of customer values.

That reading, and the change that follows a real finding, is the work. Services cover performance, recovery of systems already in production, and the connections around them. Selected work keeps each result next to the operation that produced it, not as a slogan for the whole platform. If you have the page and the symptom, send those. Leave the customer rows out.