Technical website audit,what I check before a redesign

Someone has suggested rebuilding your website, because it is slow, it is ageing or it updates badly. Before you sign, a technical website audit tells you what is actually broken and, above all, whether a redesign would fix that particular problem. Some faults survive a new site perfectly well: a badly configured cache or a poorly defined data feed will turn up unchanged in the new project.

I have carried out technical audits on client work, and my missions start with a few days of diagnosis. Here is what I look at, in what order, and how I sort what I find so that you can make a decision.

01What an audit before a redesign should help you decide

Before the first check, I ask one question: what decision will you make with this audit? A report that serves no decision ends up in a shared folder. With a redesign, there are usually three possible outcomes.

• Repair: the foundations hold, the faults are isolated, and a few fixes will do.
• Migrate: the content and structure hold up, but the tool blocks publishing, languages or integrations. That is the case I describe in migrating a website to Next.js and Sanity.
• Rebuild: the content is badly divided, the templates can no longer evolve, and repairing would cost more than starting again.

I prefer to write these three outcomes at the top of the document. They force every finding to connect to something concrete, and they stop an audit from merely justifying a redesign that has already been sold.

02Understand how the site works before running a tool

In a short Google Search Central video, Martin Splitt breaks an audit into four stages: understand the site, examine it, evaluate what you find, and explain what you recommend (How to perform a technical SEO audit). He regrets reports with arbitrary scores that are hard to interpret, and asks people not to follow their tools blindly. I agree with him about the order. A crawler run first produces hundreds of lines, and you do not yet know which ones matter for your site.

So I start with one page describing the site, without a tool, by talking to the people who look after it:

• the publishing tool, the hosting and the cache;
• how pages are produced, on the server or in the browser;
• the languages and countries targeted;
• everything connected to the site: CRM, ERP, payments, forms, analytics;
• who publishes, who has access, and who answers when the site goes down.

This page changes the rest of the audit. Splitt gives the example of hreflang tags: worth checking on an international site, pointless on a single-language one.

It also helps to spot what a crawler cannot see. A site sometimes carries more than pages. The one for Moonworkers, my company, has free calculators that I checked one by one against the official tools: losing that verification in a redesign would be far worse than a missing tag. Data matters just as much. I learned on a mission that mixing centimetres and millimetres between two tools can distort an entire render. Since then, I look for which data is the reference, and where that is written down.

03What I check, layer by layer

I work from the most blocking to the finest detail. There is no point discussing images if the server only answers half the time.

Crawling and indexing

Search Console already gives you a lot, for free. The Page indexing report shows the status of every URL Google knows about, with the reasons for non-indexing. The Crawl Stats report shows how your server responds to Google. I look at average response time and host status, because Google warns of two things there: without a valid response for the robots.txt file, it will slow or stop crawling, and when server errors rise, Googlebot reduces its requests.

Google reserves this report for advanced users and says a site with fewer than a thousand pages should not need it: on a small site, it is enough to check that the server responds properly.

404 errors need some perspective. The same help page says it is not possible, worthwhile or even desirable to fix them all. Splitt adds that a high number of 404s after removing content is normal, whereas an unexplained rise deserves investigation.

Redirects, links and rendering

I look for redirect chains and loops. Google recommends avoiding them and, where you cannot, keeping chains ideally to no more than 3 redirects (Google Search Central, how to move a site). While I am there, I start the list of URLs, from the sitemaps, the server logs and the CMS. If the redesign goes ahead, that list becomes the redirect table.

Then I look at the code the browser receives. Google says it can only discover links in `<a>` elements with an href attribute, and it still recommends server-side rendering or pre-rendering, because not all bots can run JavaScript (JavaScript SEO basics). A menu built from JavaScript buttons can look perfect to the eye and remain invisible to a bot.

Speed for your real visitors

A score measured once on a desktop machine does not say much. Field data comes from your real users and forms a distribution, and a lab test can give a different figure for the same page (web.dev, lab and field data). I compare against the thresholds Google publishes: LCP at 2.5 seconds, INP at 200 milliseconds and CLS at 0.1, at the 75th percentile, with mobile and desktop separated (web.dev, Web Vitals).

A slow page does not prove the site needs rebuilding. It is often an oversized image or one third party script too many, and that can be fixed without a redesign.

What a visitor sees without a session

This is the check I never skip. On a mission, I saw a site that looked normal to the logged-in team and was broken for visitors, because of a cache. So I check in a private window, on the public address. I send a form and see whether it arrives. I have someone publish a change and I watch when it appears.

Cookies and accessibility

Both of these belong in the redesign specification, so it is better to know where you stand beforehand. The CNIL, the French data protection authority, requires consent before the relevant cookies are set, and refusing must be as simple as accepting (CNIL, cookies and trackers, in French). I load the page without clicking anything and see what has already been set.

Since 28 June 2025, accessibility requirements have applied to certain services in France under the European directive, including e-commerce. The directive exempts businesses with fewer than 10 employees and under 2 million euros in turnover (DGCCRF, Accessibility Directive, in French). I am not a lawyer: I flag the subject, and your adviser decides on your case.

04Sort every finding into red, amber or green

I borrowed this sorting from my content machine, where a check rereads each article before publication. The rules work just as well for an audit.

1. Red: the finding stops visitors or search engines reaching the site, or touches a legal obligation. It gets dealt with, whatever is decided about the redesign.
2. Amber: the finding may be legitimate. It stays open until someone writes down why it is being kept or why it is being fixed. The 404s from an old catalogue that was removed belong here.
3. Green: the check took place and the evidence is recorded.

One rule counts more than the others: a check that did not happen is a red. The trap with any check is green by default. If I did not get access to Search Console or the server logs, I do not write it up as green or in small print at the end. It is a red until the check has been done.

Each finding fits the same six-line template:

• Finding: the contact form does not arrive when the cache is on
• Evidence: sent from a private window, nothing received
• Colour: red
• Effort: low
• Impact: contact requests are lost
• Redesign: does not fix it, the cache setting would carry over

This example shows the format, it is not a real case. The last line is the one that helps you decide: when most of the reds can be repaired without a redesign, the redesign project changes in nature. I then sort by effort and impact, as Splitt advises, and go through it all with the team. They often know why something odd was done that way, which saves me presenting a deliberate choice as a problem.

05What a technical audit will not tell you

It will not tell you whether your site persuades anyone. A technically clean site can sell nothing, because the message or the offer does not hold up. That is a matter for scoping, which I describe in scoping a digital project in a week.

Nor does it replace a penetration test. I look at certificates and headers, but a proper security review takes a specialist, and I would rather say so.

It is also a snapshot on a given date. And if you then decide to migrate, the audit does not remove the risk: Google warns that rankings can fluctuate, and that it can take a few weeks or more on a medium-sized site for the new URLs to start showing (Google Search Central, how to move a site).

Finally, a small five-page brochure site does not need it in this form. An hour with Search Console and a private window is often enough.

06Where to start your audit

If a redesign is on the table, here is what I would do on Monday:

1. Write down the decision to be made and the three possible outcomes.
2. Draft the page describing the site, with the people who look after it.
3. Gather access: Search Console, analytics, hosting, CMS. Any missing access goes down as a red.
4. Open the indexing and crawl reports, and note what is moving.
5. Test the site in a private window: the key pages, a form, a publication.
6. Sort the findings using the template above, then ask the question on the last line.

If the redesign is decided, these findings will feed your acceptance testing and go-live checklist: each red becomes a test to pass again before the switch. If you would like an outside view of your site, the services page explains how I work; we can talk about it.