A redesign changes the experience; a rebuild changes the foundation.

A website redesign normally changes positioning, information architecture, copy, visual design and conversion paths while retaining a useful content management system or application foundation. A rebuild replaces substantial parts of the technical implementation because the current platform, theme, dependencies or data model no longer support the business responsibly.

The distinction is not cosmetic. A company can completely transform the customer experience without changing platforms, or migrate to a new stack while reproducing nearly the same weak message. The correct scope depends on the constraint—not on how dramatic the new homepage looks.

Use six signals to choose the responsible path.

SignalRedesign is usually enoughA rebuild may be justified
EditingThe team can publish and update safelySimple changes require developer work or fragile plugins
PerformanceThe main problems are assets and page decisionsThe platform creates persistent speed or rendering limits
SecurityDependencies are supported and maintainedCore software or extensions are obsolete and risky
IntegrationsForms, CRM and commerce can be improvedCritical integrations are tightly coupled or unreliable
ContentUseful pages can be restructured in placeThe content model cannot represent services, locations or products
OwnershipAccounts, code and data are accessibleThe company cannot control or export essential assets

Do not confuse a content problem with a platform problem.

Many underperforming websites do not need new technology. They need clearer positioning, distinct service pages, stronger proof, a shorter conversion path and reliable lead delivery. Replatforming will not solve those decisions automatically.

Start by mapping the visitor journey and reviewing the pages that already attract traffic or support sales. If the platform can publish the required structure and maintain acceptable performance, a focused redesign can preserve budget for research, copy, proof and measurement—the work customers actually experience.

Protect organic visibility before approving either scope.

A technically cleaner website can still lose visibility when the migration removes useful content or breaks internal relevance. Search preservation is part of the redesign plan, not a checklist added after development.

  • Export the current URL inventory and identify pages with impressions, clicks, links or sales value.
  • Keep useful URLs stable where possible and map every changed URL to the closest relevant destination.
  • Preserve original information that still answers buyer questions instead of replacing it with thinner marketing copy.
  • Review canonicals, crawlable navigation, structured data, robots directives and the XML sitemap before launch.
  • Monitor index coverage, important queries, conversions and server errors after release.

Consider a phased rebuild when the risk is concentrated.

A complete replacement is not the only alternative to keeping everything. A business can rebuild the public marketing site while retaining a separate customer portal, or modernize the highest-value service cluster before migrating a large resource library.

Phasing is useful when it creates a clean acceptance boundary and measurable improvement. It becomes harmful when two systems duplicate content indefinitely or the temporary architecture has no ownership and retirement plan.

Write the decision into the project brief.

A useful proposal should explain why the recommended technical scope is necessary and which business outcome it supports. If the platform decision appears before the current system has been inspected, the recommendation is probably a vendor preference rather than a diagnosis.

  • What must improve for customers and the business?
  • Which current pages, rankings, content and integrations must be preserved?
  • Which platform constraints have been demonstrated rather than assumed?
  • Who owns content migration, redirects, analytics and post-launch verification?
  • What evidence will show that the redesign or rebuild worked?

Useful primary sources

Google Search Central — Site moves with URL changesGoogle Search Central — Redirects and Google SearchGoogle Search Central — Link best practices