Professional website redesign services
in Redwood City

A redesign usually gets judged by how it looks and how it converts. The systems that measure whether it actually improved anything get far less attention. That gap causes a familiar problem. Six months after launch nobody can say with confidence whether traffic quality, conversion rate or time on page changed at all, because the numbers before and after are not comparable.

Analytics breaks quietly during a redesign, not loudly. Page templates change, so event triggers built around specific button classes or form fields stop firing. URLs change too. A goal defined against an old thank you page path never fires again. None of this throws an error. The dashboard simply goes flat, and flat can look like calm water if nobody is watching closely.

The fix starts with an inventory, not a rebuild. Before any new page ships, list every event currently tracked: form submissions, scroll depth, video plays, outbound link clicks, add to cart actions if the site sells anything. For each one, note what triggers it today. Note where that trigger lives in the markup. That list becomes the checklist for the new build. It is far cheaper to write before launch than to reconstruct from memory after data has already gone missing for a month.

Tag management containers deserve the same treatment. A site accumulates tags over years: advertising pixels, a chat widget, a heatmap tool, a personalization script, a handful of one off campaign trackers nobody remembers commissioning. A redesign is the moment to decide, tag by tag, whether it still earns its place. Copying the container wholesale and hoping nothing conflicts with the new page structure is not a plan.

Conversion definitions need particular care. They feed decisions well beyond the marketing team. A goal built around a specific URL pattern, a specific button, or a specific number of form fields has to be rebuilt to match the new implementation before launch, not discovered broken inside a monthly report. Rebuilding it after the fact leaves a gap in the record. Nothing can fill that gap in retroactively.

Historical comparison depends on definitions staying stable across the transition. Renaming an event, changing how a conversion counts, or moving to a different measurement property all break the line between old data and new. Sometimes a definition genuinely needs to change, because the new page behaves differently. That change is worth recording somewhere permanent. A future report can then explain the jump instead of leaving it a mystery.

Testing belongs on staging, with the same rigor as any other feature. Fire each event manually. Watch it appear in a debug view. Confirm the right parameters travel with it. This catches problems while they are still cheap to fix. Finding them after launch, once a week of visitors has already passed through untracked, is a far more expensive way to learn the same lesson.

Downstream systems complicate the picture further. Retargeting audiences, lead scoring rules and sales dashboards often depend on the exact tracking setup a redesign is about to change. A remarketing list built from a pixel that no longer fires quietly stops growing. Nobody notices until an ad account flags low reach weeks later.

The most useful deliverable at the end of a redesign is not the sitemap or the style guide. It is a short document mapping every tracked metric to where it lives now: what fires it, what platform receives it, and who is responsible for checking it after launch. Redesign teams disband once the site ships. Someone still has to run the reports six months later. That person deserves a record of what changed and why.

Somewhere between the first workshop and the first wireframe, someone has to decide what happens to every page that already exists. That decision gets skipped more often than it should. The result is a new design wrapped around an old, undecided structure: the same duplicate pages, the same orphaned campaign landing pages, carried forward simply because nobody made a call.

A page inventory is the honest starting point. Every existing URL gets listed alongside its traffic, its ranking for anything it ranks for, and its actual purpose. Does it answer a question a customer asks. Does it support a sales conversation. Or does it exist because someone published it once and never revisited it. That last category is larger on most sites than anyone expects.

From there, each page sorts into one of four outcomes. Some stay close to as is. They already do their job well. Some stay but get rebuilt, because the content still matters even though the execution has aged badly. Some merge into a stronger page covering the same ground. Some get retired outright, with a redirect pointing somewhere useful instead of a dead end.

Merging deserves more thought than it usually gets. Two or three pages built at different times, aimed at slightly different phrasings of the same question, tend to compete with each other rather than reinforce anything. Combining them into one thorough page performs better than keeping three thin versions alive out of habit. Redirect the others into it.

Retiring a page is harder to argue for than adding one. It rarely happens without a clear rule. A page that gets negligible visits, answers a question nobody asks anymore, or duplicates something covered better elsewhere is a reasonable candidate. A page someone simply dislikes the look of is not the same thing. That distinction is worth holding onto once the conversation turns subjective.

Content worth keeping does not always live on a page worth keeping. A strong illustration, a well written paragraph, a useful diagram: these can move into the page that survives even when the page around them does not. Reading through the material being retired before deleting it catches value that a quick glance at analytics alone would miss.

Sequencing matters here. This sorting exercise belongs before wireframes are drawn, not after. The number of pages, their relationships to each other and their relative importance shape the navigation and the templates the designer builds. Skip that order and rework follows. Starting visual work before the content decisions are settled means redoing structure once those decisions finally get made.

The list itself is worth a sign off round before it turns into redirect mapping and build tickets. Someone in sales may know a page gets shared constantly on calls despite thin traffic. Someone in support may know a page answers a question that generates fewer tickets when it exists. A traffic report alone will not surface either fact. Skipping this round tends to surface it later, after the page is already gone.