Web Design & Development
Marketing sites and content platforms built to render fast and rank.
A redesign can lose search traffic overnight when URLs change without redirects or pages that earn traffic are cut. We plan against both before any design starts.
A website redesign rebuilds an existing site — its structure, interface, content and platform — while preserving what already works. We list every live URL, decide to keep, merge or retire each one, and test a redirect map. That way the authority the old site earned can transfer to the new one.
A good fit for
We record traffic, rankings, links and conversions per URL, so nothing is removed blindly.
The new URL plan is built against the old one, and the redirect map is written now.
The interface is rebuilt from the design system, and pages that convert are reworked carefully.
Content moves into a proper content model, not pasted into layouts, on a site search engines read.
We test redirects on a staging copy, including chains and loops, then check headings, links, accessibility and speed.
Redirects are live from the first second, rollback is ready, and the sitemap goes to Google and Bing.
For weeks after launch we watch indexing, errors, rankings and conversions.
Problem
What we do
We map every URL to its new home and test the redirects before and after launch.
Problem
What we do
We rebuild on a modern setup with a real content model and a set speed budget.
Problem
What we do
We merge duplicate pages, retire dead ones with redirects, and link the rest on purpose.
| Situation | Usual recommendation | Why |
|---|---|---|
| Site ranks, converts, looks dated | Improve in place. | The structure earns. Replacing it risks rankings for looks. |
| Content renders only with JavaScript | Rebuild. | Search engines index it unreliably; templates cannot patch that. |
| Fails Core Web Vitals on mobile | Measure first, then decide. | Images and fonts often fix in place; bloated builders rarely. |
| Platform unsupported or insecure | Rebuild, and plan the migration. | The cost of staying grows with every unpatched release. |
It can, and the risk comes from changed URLs without redirects, removed content, or a rebuild that stops rendering content server-side. Handled deliberately, the pages that earn traffic keep their content and either keep their address or are redirected one to one, which is what carries the signals they hold. Some movement while search engines recrawl is expected and temporary.
Where they are sound, yes. Keeping a URL is always lower risk than redirecting it, so we change a URL only when the existing one is genuinely harmful — a query parameter, an ID, a structure that contradicts the content plan. When a URL does change, it gets a 301 to its closest replacement.
The audit and the content decisions usually take longer than the build, and they sit on the critical path rather than beside it. A small site with clean content moves quickly. A large site with years of accumulated pages, a migration and a redirect map takes considerably longer. We give a sequence and a range after the audit.
Often, yes, and it is frequently the better call. If the platform renders server-side and performs acceptably, a new interface on the existing stack keeps the risk low. We recommend replacing the platform only when it is the thing preventing the outcome you are paying for.
Nothing is deleted without a decision. Each page is kept, merged or retired on the evidence of what it earns, and retired pages get a mapped 301 rather than a 404. We also provide the inventory itself, so you can see what was removed and why, rather than discovering it later.
Short answers are above. Open a panel below for the specifics: how we decide, what is included and the deeper questions.
Client-only rendering, unfixable performance, an unsupported platform, or a URL scheme that cannot carry the content plan. Those are the cases where improvement has a ceiling below where you need to be.
If the URLs, content and rendering are fine and the problem is presentation or page speed, consolidation and optimization cost less and keep the authority already earned.
The platform decision matters less than the mapping. Whatever you move to, the redirect map and the content inventory are what decide whether traffic survives the move.
Almost always for one of four reasons: URLs changed without redirects, pages that earned traffic were deleted, the new site renders its content only with JavaScript, or metadata and heading structure were rebuilt without regard to what ranked. All four are decisions, and all four are avoidable.
The pattern is consistent enough to plan against. A new site is designed around a new navigation, the URL scheme changes as a side effect, and the redirect list is assembled from the navigation rather than from the actual index. Every page that existed but was not in the navigation — old articles, landing pages, deep service pages — becomes a 404 with inbound links pointing at it.
By migrating value rather than layout. Each page is assessed on the traffic, rankings and links it holds; high-value pages keep their URL where possible and their substance always, and where two pages covered the same ground they are merged into the stronger URL with the other redirected to it.
Rewriting for tone is where equity quietly disappears. A page ranking for a specific query usually ranks because of particular words, headings and depth — replace them with shorter marketing copy and the ranking goes with them. Improvement means adding what is missing, not replacing what is working.
When the site blocks an outcome you can name. Common triggers are a platform that cannot render server-side, performance that cannot be fixed in place, a positioning change the site cannot express, or a content plan the URL structure cannot carry. Age alone is not a reason.
The counter-test is worth running honestly: if the site earns traffic and converts, and the complaint is that it looks old, a redesign is a presentation project with search risk attached. Scoping it that way — same URLs, same content, new interface — keeps the risk near zero.
Search visibility is lost in a redesign through a small number of specific mistakes, all of which happen at predictable points. This is the sequence that prevents them, and it starts before the design does.
Every live URL is collected from Search Console, analytics, the sitemap and a crawl, with what it earns attached to it.
Each URL gets a decision and a reason. Pages that earn traffic or links are kept; duplicates are merged into one destination.
Every changed or retired URL is mapped to its closest relevant replacement with a 301, and chains are collapsed to one hop.
The map is tested on staging: every source URL resolves once, to a live page, with no loops and no redirects to the homepage by default.
The new site goes live with the redirects already active, and with a rollback route available if something is found in the first hours.
The generated sitemap is submitted to Google Search Console and Bing Webmaster Tools the same day, so recrawling starts immediately.
Index coverage, crawl errors, rankings and conversions are watched for weeks, because a problem found in week one is still cheap to fix.
A complete URL inventory and a validated redirect map mean the links and rankings the old site earned point at the new one, rather than at a 404.
Performance, index coverage and conversions are recorded before the rebuild, so after it there is a comparison rather than an opinion about whether it worked.
Merging duplicates and retiring dead pages concentrates authority on the pages that should rank, which is frequently the fastest gain in the whole project.
Server rendering, a real content model and a performance budget replace whatever was making every improvement expensive.
Moving off a legacy CMS or a page builder, where the new URL scheme will differ and the redirect map is the difference between a good quarter and a bad one.
Two or three domains from old brands or acquisitions, each with some authority. Consolidation concentrates it, but only with a deliberate mapping of every URL.
The structure and content are sound, the presentation and performance are not. The rebuild keeps the architecture and replaces the layer that is costing visitors.
Tell us what you need and when you need it. We reply with a clear scope and the next steps.