Website Refresh

Your approved design, applied verbatim
to the existing live site.

A refresh re-skins your retained client's existing site in the new design you've approved — preserving every URL, every piece of content, every navigation pattern. Bones stay. Visuals change. The live revenue surface is protected throughout.

What refresh means

A refresh is design-led,
not ticket-led.

The agency supplies an approved Figma. We implement it on staging—template by template, with per-page exceptions where the design calls for them. Everything outside the design scope comes through unchanged: URLs, internal links, copy, navigation, forms, sitemap. A pre-cutover Screaming Frog crawl, comparing the live origin to the staging build, confirms zero structural drift before promotion.

A refresh is not a rebuild (the legacy site is replaced) and not a redesign (structure may shift, templates may be added or removed). It is a narrower brief: keep everything the same, change how it looks. If the brief crosses that boundary—templates added, navigation re-hung, content reorganised—we re-scope the engagement at intake rather than discover the mismatch mid-build.

After the design swap is signed off and live, modification tickets—copy changes, new sections, small layout tweaks—can be processed against the live site individually as an optional follow-on. The ticket queue is not the engagement; the design swap is.

How we work

Figma in. Live site re-skinned. Bones preserved.

  • Design implementation against agency Figma We build the new visual layer on staging, template by template. Per-page exceptions (a hero variant, a custom block on the About page, a calculator on a single landing page) are scoped explicitly and quoted alongside the template work. The Figma is the brief; we don’t paraphrase it.
  • Structural preservation, verified Every URL, every internal link, every form integration, every navigation entry comes through unchanged. We run a pre-cutover Screaming Frog crawl comparing the live origin to the staging build and report the diff. Zero structural drift is the deliverable—not a hope. Post-launch verification on the live domain belongs with your SEO layer.
  • Pre-cutover QA gate Site Checker—our own WordPress QA plugin—runs across core settings, content parity, URL structure, menus, and multi-resolution screenshot capture against the approved Figma. Fail-zero gate before live promotion. The agency’s own QA layer runs after, on their tools and process; we own the fix loop until sign-off.
  • Optional follow-on tickets, scoped per item After cutover, modification tickets are processed individually—each with its own hours estimate before work, each with its own Site Checker gate before close. The payer (agency manager or end client) decides which to proceed with; the running total matches the final invoice. No fixed retainer cadence; no silent hours added on top.
FAQ

Frequently asked, plainly answered.

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

  • A Refresh re-dresses an existing live site in a new design, preserving every URL, every piece of content, and the navigation structure. The agency supplies the approved Figma; we implement it on staging — template by template, with per-page exceptions where the design calls for them — verify parity with the live site, and promote on cutover. The primary deliverable is the design itself; modification tickets after the swap are an optional follow-on engagement, not part of the core scope.

  • A Redesign typically changes more than visuals — page structure may shift, templates may be added or removed, content can be reorganised; the brief is "rethink this site." A Refresh's brief is narrower: keep everything the same, change how it looks. URLs, sitemap, copy, and navigation come through the engagement unchanged; the agency-supplied design is applied verbatim. If you need structural changes, that's a Redesign engagement — we'll re-scope at intake rather than discover the mismatch mid-build.

  • Materially safer — by construction, nothing on the indexable surface changes. URLs stay the same, page titles and meta descriptions stay verbatim unless the new design explicitly changes copy on a page. We run a Screaming Frog crawl before and after the design swap to confirm zero structural drift. The ranking outcome remains yours to own and measure, but a Refresh removes the migration-related categories of risk that a full Rebuild carries (redirect-map errors, broken internal links, accidental noindex, content drift).

  • By template count, primarily. A site with 100 pages built on 10 templates is a 10-template Refresh; we re-dress each template once, and the visual change propagates to every page using it. Per-page work happens only where the new design includes page-specific elements — a hero variant, a custom block on the About page, a calculator component on a single landing page. We quote on the template count plus identified per-page exceptions, not on raw URL count.

  • Yes, as an optional follow-on engagement. Once the design swap is complete and signed off, modification tickets — copy changes, new sections, small layout tweaks, content updates — can be processed against the live site one at a time. Each ticket gets an hours estimate before work starts; the payer (agency manager or end client) decides which to proceed with; Site Checker runs before each close. There's no fixed retainer cadence — tickets land when the agency sends them, and the running total matches what's invoiced.

Have an approved design ready
for an existing live site?

Send us the Figma and the live site URL. We’ll return a fixed-hours estimate for the design swap, identify any structural changes hiding inside the brief that would re-scope it as a redesign, and quote any follow-on tickets you have queued. The live site stays untouched until the new design is signed off and ready to promote—no cost for the review, no obligation to proceed.

Scroll to Top