Build / Website Redesign
Redesigns that start with the existing URL inventory, so a relaunch improves the site without quietly discarding its search history.
TechSteps runs website redesigns that start with the existing URL inventory rather than with a visual concept. We establish which pages hold search history, traffic and links, decide where each one goes, and carry that map through to launch. A redesign should improve how the business is presented without discarding what the current site has already earned.
What this solves
A redesign is usually commissioned because the site looks dated. That is a legitimate reason, and it is rarely the whole story. The deeper issue is normally that the site describes a business that has changed.
The technical risk is separate and larger. A site that has existed for several years has accumulated search history, inbound links and pages that rank for terms nobody on the current team remembers targeting. A redesign that changes the URL structure without mapping those pages discards that quietly, and the loss appears weeks later.
We treat a redesign as two projects that have to be done together: repositioning what the site says, and migrating what it has already earned.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Before any design conversation, we establish what exists and what it is worth. This regularly changes the plan, because pages nobody remembers turn out to be earning steady traffic.
What the business leads with, who it is for, and what the visitor should do. A redesign that only changes appearance leaves the actual problem in place.
Architecture and page types agreed before visual work, so the design solves a defined problem rather than dictating one.
URL decisions are made as pages are built, not assembled in a spreadsheet the night before launch.
A full crawl against staging, with every old URL tested against the redirect map. Staging is blocked from indexing while this happens.
Redirects deployed with the site, then index coverage, crawl errors and server logs monitored through the following weeks. Most migration problems are visible early and cheap to fix if someone is looking.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Old URLs return 404 and years of accumulated search history is discarded. This is the single most common cause of the post-relaunch traffic drop.
Technically a redirect, practically a soft 404. Search engines treat it as such and the target page inherits nothing. Each URL needs an intent-equivalent destination.
A page that ranks well and converts steadily gets removed during a content cull because nobody checked its performance first.
The staging site gets crawled, duplicates the live site, and occasionally outranks it. Staging must be blocked before it contains anything real.
The project is declared complete at deployment. Problems that would have been trivial in week one are discovered in month three.
Questions we actually get asked
You should not lose it permanently. Some fluctuation is normal for a few weeks as search engines recrawl and reassess. Permanent losses almost always trace to a specific cause: missing redirects, removed content, a change in internal linking, or a new site that is slower or less crawlable. Those are preventable, which is why the inventory comes first.
Where they are reasonable, yes. Changing a URL has a cost and needs a reason better than tidiness. We change them when the structure is genuinely confusing, when pages are being consolidated, or when the existing pattern will not support the new architecture. Otherwise we keep them.
Check what each one earns before deciding. Posts with steady traffic or inbound links should be kept, updated if the content has aged. Thin or duplicated posts can be merged into a stronger page with a redirect. Posts with no traffic and no links can be retired. The decision should follow the data, not an impression of how the archive looks.
It depends mostly on content and decision-making rather than on build time. The inventory and architecture phases are usually quick. The step that stretches is agreeing what the site should say, so a decision maker who is genuinely available shortens the project more than anything else.
Yes. If the platform is serving you adequately, a redesign on top of it is lower risk and lower cost. We will tell you if we think the platform is itself the constraint, but changing it is a separate decision that needs its own justification.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.