Published Updated 6 min read
Website Audit Before a Redesign: What to Check
Why a technical audit should come before a website rebuild or redesign, what it should check, what you should receive, and how to use the findings to decide between fixing and rebuilding.
Written by Ali Abdelhadi, Founder & Lead Engineer
In this article
Short answer. Audit before you rebuild, because a rebuild built on guesses tends to repeat the old problems and lose what already worked. A useful audit checks architecture, performance, security, search and analytics, how changes are delivered, and who owns what. It ends with written findings ranked by risk and a roadmap that says what to fix in place, what to rebuild, and in what order.
Most rebuilds start from a feeling: the site is slow, hard to change, or looks dated. Those feelings are usually right, but they do not say which parts are broken, which parts are fine, and which problems a new build would quietly carry over. An audit replaces the feeling with evidence before you commit a budget.
Why audit before a rebuild
- You find out whether you need a rebuild at all. Some problems, such as slow images, a misconfigured cache or a broken analytics tag, are fixed in days without touching the rest.
- You protect what already works. Pages that rank, URLs that other sites link to, and data you have collected for years are easy to lose in a rebuild if no one listed them first.
- You scope the new build properly. A rebuild quote based on audit findings describes the real system, not an assumption about it.
- You avoid rebuilding the same mistake. If the old site became hard to change because of how content or data was modelled, a new design on the same model will age the same way. Our article on technical debt explains how that happens.
What a technical audit should check
| Area | What is examined | What it tells you |
|---|---|---|
| Architecture | How the code, data and integrations are structured | Whether the system can be extended or has to be replaced |
| Performance | Core Web Vitals on real devices, server response, page weight, third-party scripts | Which bottlenecks matter and which are worth fixing |
| Security | Authentication, exposed surface, secrets, dependency vulnerabilities, permissions | Where someone could get in today, by severity |
| Search and data | Indexability, rendering path, metadata, structured data, analytics integrity | What search cannot see, and whether your numbers can be trusted |
| Delivery | How changes are made, tested and released | Why changes are slow or risky |
| Ownership | Who holds the code, domain, hosting and accounts | What you control, and what you would lose if a vendor left |
A pre-redesign checklist you can start today
Some of this you can check yourself before talking to anyone:
- List your accounts. Domain registrar, hosting, repository, analytics, Search Console, email, payment and any other service. Note whose name each is in.
- Export your URLs. Every page that exists today, from your sitemap or a crawl. This becomes the redirect map, so no indexed page is lost. Google's site move guide explains why 301 redirects matter and how long to keep them.
- Note the pages that matter. Which pages bring visitors, leads or sales, according to your analytics.
- Check analytics health. Is the tracking tag on every page? Do form submissions and purchases register as events? Numbers you cannot trust will mislead the new build.
- Measure real performance. Look at Core Web Vitals for your key pages. Google's thresholds are published on web.dev.
- Check search coverage. In Search Console, look for pages that are not indexed and why.
- Look at security basics. Is everything served over HTTPS? Are plugins and dependencies up to date? The OWASP Secure Headers Project lists the response headers worth checking.
- Test the main tasks yourself. On your phone, in every language you serve: find a product, fill the contact form, complete a purchase.
- Write down what is hard to change. Ask the people who edit the site what takes too long. That list is often the real brief.
Checked the list and found gaps? A fixed-scope audit does the rest in five business days: start with a technical audit.
What you should receive
A useful audit is a document you can act on without the person who wrote it:
- Findings ranked by risk, with the evidence beside each one.
- A roadmap ordered by what to fix first.
- A clear recommendation: fix in place, rebuild in parts, or rebuild.
- A walkthrough with the people who will act on it.
Fix or rebuild: how to decide
| Signal | Usually fix in place | Usually rebuild |
|---|---|---|
| Performance | Bottlenecks are in images, caching or scripts | Slowness comes from the platform or architecture itself |
| Changes | Hard changes are confined to a few areas | Every change touches everything |
| Security | Issues are configuration or updates | The platform or core dependencies are no longer maintained |
| Content and data | The model fits the business | The model fights how the business works now |
| Languages | Both languages already work, with small gaps | A second language was bolted on and breaks layouts |
Most results are mixed. A partial rebuild, such as keeping the data and replacing the front end, is often the right answer.
How our technical audit works
Our technical audit is a fixed-price, fixed-scope engagement:
- Scope. The six areas above.
- Time. About five business days, counted from the day you grant read access and tell us what prompted it.
- You receive. Written findings ranked by risk, a roadmap you can run with us, with your own team or with another developer, and a one-hour debrief.
- Credit. If you then build with us, the audit fee comes off the build price. The price is on the pricing page.
If you are not sure an audit is what you need, schedule a consultation to settle what the next step should be.
Website audit: common questions
What is the difference between a website audit and an SEO audit?
An SEO audit looks at how search engines find and rank your pages. A technical audit includes that, and also looks at architecture, performance, security, delivery and ownership, which decide what a rebuild should and should not keep.
How long does a website audit take?
It depends on the size of the system. Ours takes about five business days for a focused system, counted from when access arrives; several codebases or integrations need longer.
Do I need to give code access?
It gives the most complete answer. Without it, performance and search can still be measured from outside, but architecture, security and delivery can only be partly assessed.
Will a redesign hurt my search rankings?
It can, if indexed URLs disappear or content is removed. A redirect map from old to new URLs and keeping the content that ranks are the main protections.
Starting with an audit
Start with a technical audit, read what the technical audit covers, or see the process a rebuild follows.
Technical Audit
A fixed-scope technical audit of your current site.
Send your number and we will call to confirm scope. We review your architecture, performance and security surface and hand you written findings and a remediation roadmap within five business days. The fee is 12,000 EGP, fixed before we start. The full audit fee is credited toward a subsequent build.
No pitch · No build commitment · Engineer-reviewed