Website Rebuild

When the brief says rebuild, we mean it precisely.

Your agency mapped the redirects, audited the URLs, and wrote the spec. We implement it line for line — no improvisation, no overrun, no surprises at cutover. White-label.

— Definition

What we mean by rebuild — and what we don’t.

A rebuild is the replacement of an existing live website with a new WordPress build, carried out so that every URL that already ranks, every redirect visitors already follow, and every meta tag the agency has audited arrives on the other side intact. The old site comes down; the new site goes up. The visitor lands on the same page at the same URL — only faster, with a fresher look.

In practice, that means three categories of work running in parallel. First, content migration: page-by-page parity between the original and the rebuilt version — copy matched, images replaced, forms rewired, no missing sections. Second, URL preservation: a redirect map implemented to the agency’s specification, confirmed by a Screaming Frog crawl before and after cutover. Third, spec execution: every template, every meta title, every field in the agency’s Google Sheets workbook implemented exactly as written — no interpretation, no silent adjustments.

The distinguishing constraint of a rebuild is the live revenue surface it touches: the agency’s client is already indexed, already ranking, already converting. The rebuild’s success criterion is that nothing on that surface is disturbed.

We handle same-CMS (WordPress → WordPress) and cross-CMS rebuilds. Webflow → WordPress is confirmed in our shipped corpus; for other source CMSes (Squarespace, Wix, etc.) the process adapts to whatever export the platform supports — typically content scraping plus media re-upload where exports are limited. The source platform changes the import tooling; the spec-execution discipline is identical.

vs. Build

A Build starts from a blank URL space — your Figma library, your IA, no migration baseline to honour. A Rebuild has none of that freedom: design fidelity to the existing site beats invention, and the live index sets the brief that the workbook then translates.

A Templated engagement spins a shared brand template per client — fast, repeatable, IA changes welcome. A Rebuild ships new templates per project, fitted to a URL story the agency has already mapped — no shared library, no IA reshape, original look respected.

01

Spec review and crawl baseline

Before a single page is built, we run Screaming Frog against the live site and cross-reference the output against the agency’s Google Sheets workbook. Every URL, status code, title tag, and meta description gets logged. Discrepancies between the crawl and the spec are flagged to the agency before work starts — not discovered at cutover.

02

Template-first build

Rather than rebuilding pages one by one, we collapse the sitemap into the smallest viable set of reusable Elementor templates and fit every page into them. On a typical engagement, that’s 10–15 distinct templates. This enforces visual consistency, reduces build time, and makes the QA surface predictable.

03

Redirect map implementation

Every row in the agency’s redirect tab is implemented verbatim — old path to new path, HTTP 301, no interpretation. Before cutover, a Screaming Frog crawl runs against the staging build alongside the live origin — every redirect row verified, every chain and collision flagged. The agency reviews the diff before we proceed to content parity.

04

Content parity diff

We run a page-by-page content diff between the original and the rebuild — copy matched, internal links verified, form integrations tested, image alt text preserved. Our Site Checker plugin handles the automated sweep; anything flagged is corrected before the agency’s QA layer begins. No missing sections reach handoff.

05

Pre-handoff QA gate

Site Checker runs across core settings, URL structure, content-language sanitization, and multi-resolution screenshot capture before any handoff. The gate is fail-zero: every failure is corrected; warnings are reviewed and judged non-blocking in writing. The agency’s own QA layer then runs independently, feeding issues back into a shared backlog for our fix loop until sign-off.

06

Launch checklist and handoff

A handoff checklist governs the staging-to-cutover window — every form fired on staging, every plugin and setting confirmed, the staging build sanitized of test artifacts, a broken-link crawl on staging cleared. We hand over the build clean and ready; the agency owns the cutover call and every post-launch verification on the live domain.

  • Page count 20 – 120 pages for most engagements. Dr Hardt rebuild ran 81 pages across 10 templates in 19 days — mid-scale reference; multi-location and legal megasites can run several hundred
  • Redirect count Matched 1:1 to the agency’s redirect tab. The redirect surface can outgrow the page count: Brilliant Dental’s 39-page rebuild carried 113 redirect entries from a nested-to-flat URL collapse
  • Templates built 10 – 15 reusable Elementor templates on a typical engagement; each new to this project, no shared components touched
  • QA documentation Screaming Frog crawl diff, Site Checker report, content parity record, completed launch checklist — delivered with staging hand-off
  • Hours range 25 – 125h for most agency briefs; fixed-quote, no hourly overruns
  • Calendar days 2 – 8 weeks end-to-end for typical engagements; larger multi-location and legal builds can run longer
  • Team 3 – 6 specialists per engagement — dev lead, project manager, QA / fix loop, plus additional dev or content support on larger builds
  • What drives size Template count and QA-backlog depth, not raw URL count alone
  • How to brief Google Sheets workbook (sitemap + redirect map + templates list) plus a Figma file or live URL reference
Pricing and scope signals

How engagements are scoped and priced.

Rebuilds are quoted as fixed-hours engagements. The estimate is driven by three factors: template count (how many distinct page designs need to be built), QA-backlog depth (how long the agency’s issues list typically runs), and redirect complexity (flat domain migration versus deep path restructuring). Raw page count is a secondary signal; we’ve seen 82-page rebuilds take nearly twice the hours of 81-page rebuilds based on template count alone.

There are no hourly overruns on fixed-quote work. If the scope grows — new pages added after kick-off, additional integrations, design revisions that weren’t in the workbook — we flag it before we start the additional work and return a small re-estimate. No silent hours, no surprise invoice at handoff.

To brief a rebuild efficiently: send the agency’s Google Sheets workbook (sitemap, redirect map, templates list), a Figma file or live URL reference, and your target delivery date. We return a fixed-hours estimate and a delivery window within 24 hours. Contact us to start.

Typical range
25–125h most agency rebuild briefs
2–8 wk calendar delivery window
3–6 specialists per engagement
Fixed-hours quote · NDA on request · White-label by default
FAQ

Frequently asked, plainly answered.

Specific to this engagement shape — what we mean by it, what we own, what changes the hours.

  • We don't make ranking claims — we preserve the surface your SEO strategy depends on. That means every URL in your redirect spec implemented as a 301, every meta title and description from the workbook copied verbatim, and a Screaming Frog crawl before cutover comparing your live origin to our staging build — so any drift surfaces before traffic moves. Post-cutover verification on the live domain belongs with your SEO layer; we own that nothing on the indexable surface drifts during migration.

  • You do. The redirect map and URL structure come from your audit, in your workbook. We implement them line for line — no interpretation, no silent path changes, no "improvements" suggested at cutover. If we spot a contradiction between your spec and the live crawl, we flag it before work starts and wait for your decision.

  • Yes — same playbook, different import tooling. For Webflow → WordPress, the platform's CSV export is mapped row-by-row into WordPress posts and taxonomies. For other source CMSes (Squarespace, Wix, etc.), our process adapts to whatever export the platform supports — typically content scraping plus media re-upload where exports are limited. The QA discipline is identical regardless of source: page-by-page parity check, redirect map verified, Site Checker run before handoff.

  • Two artefacts ship with the staging handoff. First, a Site Checker content-parity diff — original copy vs rebuilt copy, with anything missing flagged for review. Second, a Screaming Frog crawl of staging against the live site, comparing meta tags, status codes, and internal-link integrity. You see the diff before your QA layer begins.

  • Initial estimate is by page count, plus two additional signals: distinct templates required and redirect complexity (flat domain migration vs deep path restructure). After that, the budget boundary takes over: you set the hours ceiling at the start, we treat it as a commitment. Any variance surfaces early, not in the handoff invoice. If work beyond plan emerges — new pages, unscoped integrations, design revisions outside the workbook — we come back with a re-estimate and wait for your approval before starting the additional hours. There are no silent overruns.

Have a rebuild brief ready?

Send the workbook and the Figma. Within 24 hours: sharp questions, fixed-hours estimate, realistic delivery date. The agency stays the visible vendor; we stay out of the client conversation throughout. That’s the arrangement, and it has held across every engagement we’ve delivered.

Scroll to Top