Website rebuild, without giving up the rankings you already earned.

A website rebuild is the operation that replaces the underlying system. New stack, new content management approach, new hosting, often new integrations, often new information architecture, plus a redesigned visual layer built on top. The visual layer is one of seven things that gets touched, not the only thing.

The seven things a rebuild changes, in roughly the order they affect the engagement scope: the rendering stack (templated SaaS to a modern framework, or one framework to another), the content management approach (page-builder to headless CMS, or proprietary CMS to a more flexible one), the hosting and edge layer, the third-party integrations (payment, scheduling, CRM, marketing automation), the information architecture (URL structure, navigation, page hierarchy), the content itself (rewrites, consolidation, and deletion), and the visual layer.

The longer reference on which operation fits which problem, and when a rebuild is the right call versus when a redesign is, lives at Redesign vs Rebuild. That page is the right starting point if you are not yet sure which operation your site needs. This page is for the buyer who has already concluded that a rebuild is the right call and wants to understand how the engagement actually runs.

Signal preservation is the part of the rebuild methodology that vendor proposals consistently under-scope and that carelessly executed rebuilds consistently fail. The difference between a rebuild that loses 5 percent of organic traffic and a rebuild that loses 50 percent is not the framework choice, the visual quality, or the timeline. It is whether the rebuild was treated as a deliberate signal-preservation operation or as a throw-away-and-restart project.

The methodology has six concrete pieces, all of which run before any new code ships to production.

First, document every URL on the existing site, with its current page title, meta description, canonical tag, heading hierarchy, and the body word count. This is the baseline. For service business sites under five hundred pages, this takes one to two days. For larger sites, the tooling matters more but the operation is the same.

Second, identify the URLs that actually carry organic traffic and conversion signal. Google Search Console plus analytics tells you which pages are doing the work. The high-traffic pages, the high-converting pages, and the high-authority pages (most external backlinks pointing in) are the protected set. Most of the engagement's signal-preservation effort focuses on these specific URLs.

Third, map every old URL to a new URL. Most rebuilds are opportunities to clean up legacy URL structure, but every old URL needs a 301 redirect to a new URL of the same or better content. Lost or broken redirects are the single largest cause of post-rebuild traffic collapse.

Fourth, preserve the heading hierarchy and the body content of the protected pages where possible. The visual presentation can change; the underlying content should rarely shrink without a deliberate reason. The new site can be more concise overall, but the high-traffic pages carrying the organic position deserve careful editing rather than wholesale rewriting.

Fifth, run a parallel deployment for at least seventy-two hours before cutover. The new site lives on a staging URL while the old site continues to serve production traffic. The team validates rendering, redirects, integrations, and analytics on the staging URL against real workloads. Cutover happens during a low-traffic window with the old site held warm in case rollback is needed.

Sixth, submit the new sitemap to Google Search Console at launch, monitor coverage and rendering for the first thirty days, and run a Pathlight scan against the new live URL weekly for the first ninety days. The first thirty days are when most signal loss surfaces; catching it early and patching while Google is still re-crawling is the difference between a 5 percent dip and a 50 percent collapse.

The default stack for a service-business rebuild is Next.js on the App Router, deployed on Vercel, with a headless CMS when editorial workflow matters and Markdown-based content when it does not. The longer reference on what the stack buys you is the Next.js development page, which covers the architectural decisions in detail.

For rebuilds specifically, three stack decisions deserve explicit attention. First, whether the new stack is headless or fully custom. Most service businesses are better served by a headless pattern (the existing CMS stays as the content source, the new front-end renders from it) because the editorial team is already trained on the existing CMS and the migration cost is far lower than a full content-management replacement. The exception is when the existing CMS is itself the binding constraint, in which case the rebuild includes a CMS migration to something the team can actually use.

Second, whether the rebuild includes a custom internal tools layer. For service businesses with internal admin needs (inventory, scheduling, customer management), the rebuild is often the right window to add a small custom admin tier rather than continuing to subscribe to a third-party SaaS that does not quite fit. Whether that fits the engagement scope is a discovery-call decision.

Third, the integration surface. Rebuilds are often motivated by integration ceiling pain (the existing stack could not integrate with the systems the business now relies on). The new stack should explicitly support the integrations the business has outgrown, with the integration work treated as first-class scope rather than as a bolted-on afterthought. Discovery covers the specific integrations and what their implementation looks like.

A typical service-business rebuild runs ten to fourteen weeks from kickoff to launch, plus a thirty-day post-launch optimization window. The work splits into four phases.

Discovery and baseline (one to two weeks). The protected URL set is identified, the existing performance and conversion baselines are documented, the integration surface is scoped, the content audit runs, and the information architecture proposal is approved. The deliverable is a baseline document the entire rest of the engagement runs against.

Architecture and design (two to three weeks). The new stack is chosen and stood up, the headless or fully custom decision is made, the redirect map is drafted from the existing URL inventory, the visual system is designed against the actual content rather than against placeholder copy, and the first interior template is built end-to-end as a prototype.

Build (four to seven weeks). Pages are built against real content, integrations are wired and tested, the redirect map is implemented and tested for every old URL, the performance budget is enforced page by page, and the accessibility audit runs continuously rather than as a launch-week check.

Launch (one to two weeks). The parallel deployment runs for seventy-two hours minimum on a staging URL with real analytics and search console monitoring. Cutover happens during a low-traffic window. The first seventy-two hours post-cutover are watched closely for redirect failures, rendering issues, or analytics gaps. Most issues that surface in the first three days are fixable before they affect organic position.

A successful rebuild is measurable at three checkpoints.

At launch plus thirty days. Organic position has lost less than five percent on the protected URL set. Core Web Vitals are passing on at least seventy-five percent of pages. Conversion rate is at parity with the pre-rebuild baseline or higher. No redirect failures in Google Search Console. Analytics is reporting cleanly with the new event model mapped to the previous one.

At launch plus ninety days. Organic position has recovered to pre-rebuild levels and started to grow on the protected URLs. Conversion rate has lifted ten to thirty percent on the high-traffic pages because the new site is measurably faster and the conversion architecture has been tightened. The team is shipping content updates without a developer, the integration surface is healthy, and the maintenance retainer is at or below pre-rebuild levels.

At launch plus one year. The site is measurably ahead of where the pre-rebuild trajectory would have placed it on every business metric that matters: organic traffic, conversion rate, lead quality, maintenance cost, and per-change velocity. The compounding benefit of a clean rebuild is most visible at twelve months and beyond, which is why the lifetime of a careful rebuild is five to eight years before structural rework rather than two to four years for a redesign.