Teams often use refresh, redesign, rebuild, and migration as interchangeable labels. That makes proposals difficult to compare. One provider may quote a refresh that includes a new design system and rewritten pages; another may call the same work a redesign. Define the layers being changed before discussing the label. The depth of change determines discovery, content work, testing, migration risk, and who must participate.

Four different projects can hide behind “update our website”

Use these definitions to align the brief and the proposal.

ProjectPrimary layer changedUsually preservedTypical reason
RefreshVisual styling, selected copy, media, and individual componentsPlatform, URL structure, navigation model, and most templatesThe site is fundamentally sound but looks inconsistent or communicates an older brand
RedesignInformation architecture, journeys, templates, design system, and content presentationDomain, some valuable URLs and content, core business systemsThe experience no longer fits the audience, offer, or sales process
RebuildFront-end or back-end implementationApproved experience and often the same platform or data modelCode quality, performance, maintainability, or accessibility cannot be repaired safely
Replatform or migrationCMS, commerce engine, hosting architecture, or domain environmentBusiness intent, selected content, data, and often visual directionThe current platform blocks operations, ownership, security, integration, or growth

These projects can overlap, but they should not be bundled by accident. A redesign might be implemented inside the current platform. A nearly invisible rebuild might reproduce the current design with cleaner code. A replatform might preserve every public URL and much of the appearance. Separating the layers keeps the business from paying for a platform change when the real problem is unclear messaging—or applying new colors to an information structure that no longer works.

Start with the decision tree, not the mood board

Choose the shallowest change that solves the root problemMove deeper only when the existing layer cannot support the required outcome.
01Business fitAre audience, offer, proof, and next actions still accurate?
02Experience fitCan the current structure support clear journeys and accessible patterns?
03Technology fitCan the platform implement, manage, and maintain those requirements?
04Change depthRefresh, redesign, rebuild, or replatform

Ask these questions in order

01

Is the business represented accurately?

Check services, audiences, markets, pricing approach, proof, people, locations, and the path from interest to inquiry or purchase. If these changed, simple styling will not be enough unless the current page structure can absorb the new story.

02

Can people complete the important tasks?

Test on phones and desktops. Find a service, compare options, locate proof, submit an inquiry, use the keyboard, recover from a form error, and understand what happens next. Repeated journey or component failures support a redesign.

03

Can staff operate the site without fragile workarounds?

Watch someone publish a normal update. If the content model is appropriate and editing is safe, preserve it. If every change requires a developer or duplicates data, redesign the content structure or consider the platform.

04

Can the current technology deliver the approved requirements?

Verify support status, integrations, performance constraints, permissions, exports, hosting, and ownership. Do not assume a replatform is needed because the admin interface is unfamiliar; document the specific blocked requirement.

05

Will URLs or domains change?

Any URL change creates migration work. Google recommends mapping old URLs to new destinations, using permanent server-side redirects, updating internal links and canonicals, and monitoring the move. A small visual refresh should avoid this risk unless a structural benefit justifies it.

When a refresh is the responsible choice

  • The current navigation labels and page groupings match how customers understand the business.
  • Most content is accurate; changes are targeted updates rather than a new messaging strategy.
  • The main forms, booking paths, and transactions work and are measured.
  • The platform is supported, accounts are controlled by the business, and routine updates are manageable.
  • Accessibility problems are limited to fixable content or component issues rather than repeated template defects.
  • Valuable pages already serve their search intent and do not need new URLs.
  • The brand system needs consistent typography, color, spacing, imagery, or component polish without changing the visitor journey.

A refresh can still be serious work. It may include a tightened visual system, clearer opening sections, better evidence, new photography, improved form copy, repaired focus states, image optimization, and a disciplined component library. The boundary is that these improvements fit inside a sound architecture. Review the 15 redesign warning signs if the team is unsure whether the problems are isolated or repeated.

When redesign depth is justified

Surface issueUnderlying redesign issue
“The home page feels busy”Spacing and hierarchy are inconsistentToo many audiences and offers are competing because the site has no routing strategy
“The menu is too long”A few obsolete links remainServices and resources lack a coherent hierarchy or naming system
“The form is ugly”Fields need visual cleanupThe inquiry process asks the wrong questions and routes every lead to the same place
“Staff cannot update it”Permissions or training are missingThe content model cannot represent reusable services, people, locations, or case studies
“Search traffic is weak”Metadata and internal links need focused workPage purposes, content depth, crawl paths, and URLs do not match real search intent

A redesign is appropriate when the team must decide what pages exist, what each page promises, how people move among them, which proof appears where, and how content is reused. That process should include content and accessibility from the beginning. W3C's evaluation resources distinguish quick preliminary checks from fuller conformance evaluation; a redesign is an opportunity to build accessible patterns, but a launch-day scan cannot establish that every person and process is served.

A professional website design engagement should document which layers are preserved and which are approved for change. Ask to see the proposed sitemap, template list, content responsibilities, component system, functional requirements, accessibility approach, migration plan, testing responsibilities, and post-launch operating model. A beautiful concept image does not answer those questions.

VISUAL CHECKPOINT · RedesignChoose the shallowest change that solves the root problem

Move deeper only when the existing layer cannot support the required outcome.

Do not replatform without a platform-level reason

  • The current product is no longer supported or cannot be kept secure within an acceptable operating plan.
  • Required content types, permissions, localization, commerce, or integrations cannot be implemented reliably.
  • The business cannot obtain needed ownership, exports, access, or vendor independence.
  • Publishing and quality control require repeated manual work that a suitable content model would remove.
  • Performance or accessibility limits are rooted in the implementation and cannot be corrected within the current stack at reasonable risk.
  • The organization has the people, budget, testing time, and post-launch process to operate the replacement platform.

A platform migration is not automatically an upgrade. It introduces data mapping, URL handling, redirects, account setup, permissions, analytics, forms, integrations, training, and deployment risk. Google treats domain and URL changes as site moves and advises changing one thing at a time where possible. If the brand redesign and domain move can be separated, the team may gain a clearer baseline and easier diagnosis, though business constraints sometimes require a combined launch.

Compare proposals by deliverables and risk

The same project label can conceal very different work.

QuestionRefresh proposal should explainRedesign or migration proposal should add
What changes?Named pages, components, copy, media, and stylesSitemap, templates, content model, journeys, URL changes, data, and integrations
What stays?Current platform, URLs, navigation, and stable contentProtected content, valuable URLs, accounts, data, proof, and required functions
How is it approved?Visual direction and page-level revisionsDiscovery decisions, content gates, prototypes, migration review, and launch authority
How is it tested?Responsive pages, links, forms, accessibility checks, and trackingRedirects, canonical URLs, structured data, content parity, permissions, integrations, and rollback readiness
What follows launch?Maintenance of changed componentsMigration monitoring, issue triage, staff training, and ownership handoff

A practical scoping exercise for leadership

Run a 60-minute change-depth workshop

01

Name the business event

Write why this conversation started: new positioning, weak inquiries, a rebrand, staff frustration, technical risk, or executive preference. Separate the trigger from the diagnosis.

02

List protected assets

Record pages, rankings, links, data, proof, accounts, workflows, and brand elements that already have value. Preservation is part of scope, not an afterthought.

03

Map every requested change to a layer

Mark each request as content, visual system, page structure, journey, code, platform, or domain. Clusters reveal the actual project type.

04

Identify the deepest necessary layer

Do not go deeper because it sounds more complete. Go deeper only when the higher layer cannot solve the documented requirement without fragile workarounds.

05

Choose sequencing

Decide what can be released independently, what requires a shared launch, and what should wait for evidence from an earlier phase.

A refresh is not the cheap version of a redesign, and a redesign is not automatically more strategic. Strategy means choosing the intervention that fits the evidence. Preserve what works, change what blocks the business, and make every deeper layer earn its added cost and risk.

Is changing colors and fonts a website redesign?

Usually it is a visual refresh if the sitemap, templates, content model, journeys, URLs, and platform remain stable. Project labels vary, so put the preserved and changed layers in the contract.

Can we redesign without changing our website platform?

Yes. If the current platform can support the approved structure, components, accessibility, performance, editing, and integrations, it may be the safest implementation choice. Replatform only for documented platform-level needs.

Does a redesign require changing URLs?

No. Keep useful URLs when their page purpose remains valid. If URLs must change, create one-to-one mappings where equivalent destinations exist, implement permanent redirects, update internal signals, and monitor the move.

Should we rebrand before or during the redesign?

The site needs enough approved brand strategy to make durable design and content decisions. Discovery can overlap, but repeated changes to positioning, naming, or visual identity after templates are built cause rework. Define decision gates before production.