Service
A website redesign that does not cost you your rankings
The most common way a redesign goes wrong is not the design. It is that the new site ships with new URLs, no redirect map, and traffic that took four years to build disappears in a fortnight. Preventing that is a checklist, not a talent, and it is included here rather than sold as an extra.
- Starting from
- $120
- Timeline
- 5 days
- Proof
- 3 live sites
- Aftercare
- 30 days
What website redesign actually means
A website redesign rebuilds the presentation of a site that already exists and, critically, already has search history. That history is the asset, and it is the thing most redesigns damage — not through bad design, but through new URLs shipped without a redirect map.
The design work is the visible half. The half that determines whether the project was worth doing is a crawl taken before anything changes, a decision recorded for every existing URL, and a verification pass after launch. That sequence is not glamorous and it is the whole difference between a redesign that lifts traffic and one that quietly halves it.
Who this is for
- Businesses with a site that ranks but looks a decade old and fails on mobile
- Companies whose site is slow enough that the speed is costing conversions
- Organisations that have rebranded and need the site to match
- Businesses on a platform they want to leave without losing their search position
- Anyone whose site was built by someone who is no longer contactable
Who it is not for
Saying this out loud costs me some enquiries and saves both of us the ones that would have gone wrong. If you are on this list, I will tell you in the first reply rather than after a deposit.
- Sites with no traffic and no rankings — that is a new build, and pretending otherwise adds cost
- Businesses that want a redesign because the site looks dated but it ranks and converts well. Sometimes the honest advice is to leave it
- Anyone unwilling to keep the content. A redesign that also rewrites everything is two projects and should be priced as two
- Sites where the real problem is the content, which a new coat of paint will not fix
The problems it solves
- Traffic collapses after relaunch
- Every existing URL is crawled first and mapped to a destination, redirected in a single hop, and verified after launch.
- Rankings lost with no idea why
- A recorded baseline means a drop can be diagnosed instead of guessed at.
- The new site is slower than the old one
- Core Web Vitals are a build target with numbers, measured before and after rather than hoped for.
- Content quietly lost in the move
- The pre-crawl is the inventory. Nothing disappears without someone choosing to retire it.
- Structured data broken by new templates
- Schema is rebuilt for the new page types and revalidated on staging.
- Staging site indexed by accident
- Staging is noindexed and access-controlled while it is built, then the block is removed deliberately at launch.
What you get
- Full crawl of the existing site before anything changes, so nothing is lost by accident
- A URL-by-URL redirect map, in a single hop, tested before launch and again after
- Modernised responsive design built mobile-first, on the content you already rank for
- Content migration with headings, internal links and metadata preserved deliberately rather than by luck
- Core Web Vitals brought inside the thresholds during the rebuild — images, fonts and render path
- Structured data rebuilt to match the new page types
- Post-launch indexation check: Search Console coverage, sitemap resubmitted, 404s monitored
- 30 days of snag fixes after go-live
What is included in the starting price
Everything below is in the $120 figure. Nothing here is quoted as an extra once the build is underway, which is the point of publishing it.
- Full crawl and inventory of the existing site before any change
- Baseline of rankings, traffic and indexed pages, recorded and shared
- URL-by-URL redirect map, single hop, tested in bulk before and after launch
- Modernised responsive design, built mobile-first
- Content migrated with headings, internal links and metadata carried across deliberately
- Core Web Vitals brought inside the thresholds during the rebuild
- Structured data rebuilt for the new templates and revalidated
- Post-launch indexation watch: coverage, sitemap resubmission and 404 monitoring
- 30 days of snag fixes after go-live
What costs extra, and why
A quote that omits these is not cheaper — it is less honest. Each one is real work that someone has to do, and pretending otherwise is how a fixed price becomes a negotiation in week two.
- Content rewriting
- Migration preserves what you have. Rewriting it is a separate piece of work with a separate value.
- Platform migration
- Moving off WordPress or a hosted builder adds export, transformation and a bigger redirect map.
- New photography or brand work
- Worth commissioning where the brand is the reason for the redesign. Not supplied here.
- Large URL restructures
- Sometimes correct, always a bigger redirect map, and always quoted on the crawl rather than a guess.
- Ongoing SEO after relaunch
- The redesign protects what you have. Growing it afterwards is a retainer.
How the work runs
- Baseline. Crawl, rankings and traffic recorded before a single change. Without a baseline, nobody can tell a redesign problem from a seasonal dip.
- Plan. The new structure mapped against the old one. Every URL either survives, redirects somewhere specific, or is consciously retired.
- Rebuild. The new design on a staging URL, noindexed while it is being built so it cannot compete with the live site.
- Verify. Redirects tested in bulk, structured data revalidated, and the crawl repeated against staging to catch what moved.
- Launch and watch. Go live, resubmit the sitemap, then watch coverage and 404s for the fortnight where problems actually appear.
Day by day
5 days from the day scope is signed off. Published as a schedule rather than a promise of speed — you should be able to tell on day three whether a build is on track.
| When | What happens |
|---|---|
| Day 1 | Crawl and baseline. Every URL, every title, current rankings and traffic recorded before anything moves. |
| Day 2 | Structure and redirect map. Every URL survives, redirects to a specific destination, or is consciously retired. |
| Days 3–4 | The rebuild on a noindexed staging URL, with content migrated and metadata carried across. |
| Day 5 | Verification and launch: redirects tested in bulk, schema revalidated, then go live and resubmit the sitemap. |
| Days 6–35 | Watch coverage, 404s and rankings through the fortnight when problems actually surface. Snags fixed free. |
The technology
Deliberately boring, and that is the feature. A stack another developer can pick up is worth more to you than one that impresses other developers.
- Crawling
- A full site crawl for the inventory, plus Search Console data for URLs that receive traffic but are not linked
- Build
- Static HTML or WordPress, matching what you need to be able to edit afterwards
- Styling
- Tailwind CSS, mobile-first, with the old design as a reference rather than a constraint
- Redirects
- Server-level rules in .htaccess or host configuration, single hop, never chained
- Verification
- Bulk redirect testing before and after launch, and structured data revalidated against the live pages
What it integrates with
- Google Search Console, for the coverage and performance baseline
- Analytics, carried across so historical comparison remains possible
- Google Business Profile, updated where details change
- Any existing forms, booking tools or payment flows, retested after the move
- Third-party scripts audited during the move — a redesign is the best chance to remove what nobody uses
What I need from you
Short list, and the first item matters most. Projects do not usually slip because the code was hard — they slip because a decision waited a week.
- Access to the current site, hosting and DNS
- Search Console and analytics access, or permission to request it
- A decision on which pages are being retired rather than kept
- Brand assets if the design is changing, or a decision to work from what exists
- One person who can approve the design without a committee round trip
Content and photography
The strongest argument in a redesign is usually to change less than you want to. Pages that rank are ranking for reasons that are not always visible, and rewriting a page that already performs is a bet placed against evidence you already have.
Where content genuinely is the problem — thin service pages, a blog of announcements nobody searched for — deal with it as a deliberate second phase after the redesign has landed and stabilised. Doing both at once means that when traffic moves, you cannot tell which change caused it.
Performance standards
Targets, not aspirations — measured before handover on a throttled mobile connection rather than on a fast laptop.
| Metric | Target |
|---|---|
| Largest Contentful Paint | Under 2.5s on a mid-range Android over 4G, measured in the field rather than on my laptop |
| Interaction to Next Paint | Under 200ms — which mostly means shipping less JavaScript rather than reordering it |
| Cumulative Layout Shift | Under 0.1: every image carries width and height, fonts have metric-matched fallbacks |
| Total page weight | Budgeted before the build, not discovered after it |
Accessibility standards
| Standard | WCAG 2.2 AA as the build target, tested rather than asserted |
|---|---|
| Keyboard | Every interactive element reachable and operable without a mouse, with visible focus |
| Contrast | Text at 4.5:1, interface elements and icons at 3:1, checked with a contrast tool not by eye |
| Motion | Anything animating over five seconds gets a pause control — WCAG 2.2.2 is a Level A requirement |
| Forms | Real labels, errors described in text next to the field, no colour-only signalling |
| Why it matters commercially | The European Accessibility Act has applied to consumer e-commerce since June 2025, and the obligation sits with the business selling, not the agency that built it |
This site is built to the same standard it sells, and the accessibility statement lists what is conformant and what is not — which is the part most statements leave out.
Security practices
| Transport | HTTPS enforced in a single redirect hop, HSTS enabled |
|---|---|
| Headers | CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and COOP set |
| Database | Prepared statements everywhere. Not "mostly" — everywhere |
| Input | Validated server-side, because client-side validation is a convenience and not a control |
| Secrets | Environment variables, never in the repository, never in a JavaScript bundle |
| SPF, DKIM and DMARC aligned so your order confirmations reach inboxes |
The SEO included in every build
Not an upsell. A site that launches unindexed is a shop with the shutters down, and the work below is cheap during a build and expensive afterwards because the fixes are structural.
| Rendering | Content present in the HTML without JavaScript execution, so every crawler and answer engine can read it |
|---|---|
| Indexation | One canonical per page, generated XML sitemap, robots.txt that does not block what it should not |
| Structured data | A linked JSON-LD graph — Organization, WebSite, page type and the commercial type that fits |
| AI crawlers | Access verified per user-agent before launch, because a host can 403 GPTBot before robots.txt is read |
| Search Console | Verified and the sitemap submitted at launch, so the site goes live indexed rather than as a blank shell |
Ownership and handover
You own everything: the domain registered to you, hosting in your account, code in a repository you control, and the payment provider account in your business name. Credentials are handed over as they are created rather than at the end.
A supplier who resists this is protecting recurring revenue rather than your interests. If you want the reasoning in full, including how to check your current site, there is a guide on it.
Aftercare and what happens after launch
Thirty days of snag fixes are included. A snag is something that does not work as scoped — not a new feature, and the difference is written down before launch rather than argued about after it.
You also get written handover documentation aimed at whoever maintains the site next, which may well not be me. That is deliberate: the test of a good handover is whether another developer could take over without calling me, and on my projects they can.
Ongoing maintenance
Optional, monthly, cancellable. Nothing here is required to keep what you paid for.
| Retainer | From | Covers |
|---|---|---|
| Maintenance | $50/month | Software, plugin and dependency updates; Automated backups with restore tested quarterly; Uptime monitoring with alerting |
| SEO retainer | $80/month | Monthly technical crawl and fix cycle; Search Console monitoring and issue resolution; Content briefs based on your real query data |
Payment terms
| Working hours | Mon–Fri, 09:00–18:00 PKT (UTC+5). That overlaps 05:00–14:00 UK time and 00:00–09:00 US Eastern. |
|---|---|
| Response time | Within one business day, always. If I will be unreachable for longer, you know before it happens. |
| Meetings | Google Meet or Zoom, scheduled in your timezone. I will take an early or late call to reach you — that is my problem to solve, not yours. |
| Language | All work, documentation and communication in English. |
| Payment | 40% deposit, 60% on completion. Bank transfer or Wise. Invoices issued for your records. |
| Currency | Quoted in USD by default. GBP, CAD or EUR on request. |
How this compares to the alternatives
Including the routes that do not involve me, because a comparison that only flatters the author is not a comparison.
| Route | Cost | What you trade |
|---|---|---|
| Rebuild with no redirect map | Cheapest | The search history you spent years building |
| Theme swap on the existing platform | Low | Design freedom, and often the speed problem stays exactly where it was |
| This redesign | Starting from $120 | Five days and a real inventory, in exchange for rankings that survive |
| Agency redesign | Several thousand | Budget, in exchange for design exploration and a longer process |
What could go wrong, and how it is handled
- The old site has more URLs than anyone thought
- The crawl exists to find that. The redirect map is quoted on what is found, not on what was assumed.
- Rankings dip briefly after launch
- Normal for a week or two as pages are recrawled. It is watched, and a dip that persists past a fortnight gets investigated.
- Content owners disagree about what to retire
- Decided on day two, in writing, before the build. Retiring a page after launch is a redirect, not a discussion.
- The current site has no analytics history
- Then a baseline cannot be reconstructed. You are told at the start, because it changes what can be verified afterwards.
Live builds you can open
Every project below is live right now. Nothing here is a mockup, a concept piece or a template screenshot, and the build fails if any of these URLs stops responding.
Wardrobe Store UK
Responsive e-commerce site for a UK wardrobe retailer - product pages with cart / checkout and extensive on-page and technical SEO (schema, meta tags, location pages).
wardrobe-store.co.uk ↗TraderGrowz
Designed and built a responsive multi-page website for a Canada-based trading brand.
tradergrowz.ca ↗Curtain House
E-commerce store for a Pakistan-based retailer of premium curtains, blinds, and home textiles with custom-stitching options.
curtainhouse.pk ↗Case studies
What the brief was, what I built and the decisions worth explaining. No invented traffic figures — every number on this site is one I can evidence.
What to measure after launch
A site with no measurement is a site nobody can improve. These are the numbers worth watching, in the order they matter.
- Indexed page count before and after, which should not drop unexpectedly
- Search Console clicks and impressions across the four weeks after launch
- Redirect coverage: how many old URLs return 301 to a live destination rather than 404
- Core Web Vitals field data, compared against the pre-redesign baseline
- Conversion rate before and after, which is the number the redesign was actually bought for
- 404 volume in server logs, watched daily for the first fortnight
Common mistakes in this kind of project
Every one of these has been found on a real site, several of them on this one before it was rebuilt.
- No crawl before the rebuild
- Without an inventory there is no way to know what was lost until traffic tells you.
- Chained redirects
- Old URL to interim URL to new URL dilutes signals and slows every request. Single hop, always.
- Launching the staging site indexed
- Duplicate content competing with your own live site, and a real risk on every redesign.
- Rewriting content and redesigning simultaneously
- Makes the result impossible to attribute when traffic moves either way.
- Removing the blog because it looks untidy
- Those URLs often hold links and rankings. Retire deliberately, and always redirect.
Glossary
Terms that come up in quotes and get nodded at rather than asked about.
- 301 redirect
- A permanent redirect. The correct one for a moved page, and the one that passes signals.
- Redirect chain
- One redirect pointing at another. Slower, and it dilutes what is passed through.
- Crawl
- An automated pass over every reachable URL, producing the inventory a redesign depends on.
- Baseline
- Traffic, rankings and coverage recorded before changes, so afterwards can be compared to before.
- Orphan page
- A page with no internal links pointing at it. Redesigns create these easily.
- Coverage report
- The Search Console view of what Google has indexed, excluded, and why.
Guides on this subject
Free, ungated, and written from client work. If reading one convinces you I know what I am doing, the enquiry follows on its own.
Questions people ask before hiring
- Will a website redesign hurt my Google rankings?
- It can, and it usually does when the redirect map is an afterthought. Done properly, rankings hold and often improve because the rebuild fixes speed and structure at the same time. The measurable difference is entirely in the preparation, which is why the crawl happens before the design.
- Can you redesign my site without changing the URLs?
- That is the preferred option and the safest one. URLs only change when the existing structure is actively causing a problem, and when they do change, every old URL redirects in a single hop to its closest match.
- How long does a website redesign take?
- Five days for a standard business site where the content is being carried over. Larger sites and content rewrites add time, and the redirect map grows with the page count — I quote on the crawl, not on a guess.
- My site is outdated but still ranks. Should I leave it alone?
- Sometimes yes. If it ranks and converts, a redesign is a risk taken for aesthetics. The honest test is whether it fails on mobile, on speed or on accessibility — those cost you money now. Looking dated on a desktop monitor mostly costs you pride.
Every other question I get asked → · or just ask me directly
Website redesign by location
Same fixed scope and the same $120 starting price, priced in the local currency with that country's tax and data-protection terms set out in full.
- Website redesign Islington
- Website redesign Naas
- Website redesign Hamilton
- Website redesign Boston
- Website redesign Albury
- Website redesign Dubai
- Website redesign Riyadh
- Website redesign Multan
- Website redesign Lucknow
- Website redesign Jurong
- Website redesign Pretoria
- Website redesign Berlin
- Website redesign Groningen
- Website redesign Paris
Other services
Need website redesign?
Send the brief and you get a reply within one business day — either questions, or a scoping call. If your project is not something I should take on, I will say so then.
- Response
- Replies within 1 business day
- Hours
- Mon–Fri, 09:00–18:00 PKT — overlaps 05:00–14:00 UK, 00:00–09:00 US Eastern
- Booking
- Booking projects from October 2026