Two projects often get confused because both involve a designer working on an existing website. One replaces the site from the ground up, while the other changes how it looks without touching the structure underneath. Knowing what a business actually needs saves months of unnecessary work, and a web designer in san francisco will assess the current site before recommending either, because the right answer depends on what the existing build can support rather than on how dated it appears on the surface.
What each project replaces?
A visual refresh replaces colour, typography, imagery, and surface layouts. The site architecture, URL structure, navigation logic, and content management system remain exactly as they were before the refresh began. Any structural limitation present in the site before the refresh remains present after it, because the refresh does not reach the layers where those limitations sit.
A full rebuild replaces every layer of the site, starting from the architecture. The navigation gets designed from the first page rather than updated within the existing structure, the content management system gets selected for the business’s current and future requirements rather than inherited from a previous decision, and features that the old build could not technically support become available because the underlying system now allows them. Structural limitations that required workarounds in the existing site get removed at the architecture stage rather than carried forward under a new visual appearance.
Content moves differently
A refresh carries existing content into the updated design. Pages earning consistent search traffic keep their addresses, so the visibility attached to those addresses does not reset, and the content on those pages gets cleaned and reorganised within the new design rather than replaced. A rebuild treats content as a separate workstream with its own tasks, owners, and deadlines running alongside the design and development stages.
- A content audit records which pages carry forward, which get consolidated, and which get retired before migration begins.
- New pages get planned and briefed for services or topics the previous site did not cover adequately.
- Existing copy gets rewritten to match the new structure, page hierarchy, and agreed voice before it enters the new build.
- Retired page addresses get redirected to their replacements, so search visibility transfers rather than disappears when the old pages go offline.
Rebuilds that treat content as an afterthought rather than a parallel workstream produce new sites carrying the same content problems the previous version had, which is the most consistent reason rebuilt sites underperform against the expectations set for them at the start.
Schedules reflect each scope
- Refresh delivery – A refresh completes in weeks because no architecture decisions need making, no new systems need configuring, and feedback rounds address visual changes rather than structural ones. The live site continues operating normally throughout the refresh because work happens on a separate version until the updated design is ready to replace it.
- Rebuild delivery – A rebuild runs across months because discovery, architecture, design, development, content production, and testing each occupy a dedicated stage that cannot begin until the previous one produces outputs for it to work from. Compressing any stage pushes unresolved decisions into the next one, where resolving them takes longer than it would have at the correct stage.
A rebuild and a refresh are not degrees of the same project, and treating them as interchangeable leads to commissioning work that either does too much or stops short of what the business needs. The assessment separating them clearly takes one afternoon and earns that time back across the months that follow.
