Redesign vs refresh vs rebuild — which do I need

Pick the smallest job that matches the actual leak. Visual age on a stack you can still edit is a refresh. Conversion drop on a stack that still works is a redesign — same URLs, new composition, new proof, same engine. CMS or platform lock — you cannot ship the pages, motion, performance, or exit you need — is a rebuild. Boredom is not a diagnostic. This spoke sits under Websites That Feel Like Films.

I have shipped hundreds of production sites. The expensive mistake is buying a rebuild because the homepage looks tired, or buying a paint pass because the CMS cannot grow. Name the symptom first.

The short answer

• Refresh when the site still converts and the CMS still cooperates, but type, color, photos, and spacing read as last decade.
• Redesign when sessions hold and the ledger (calls, forms, bookings, checkout) fell — after tracking is proven — and the stack can still host the new system.
• Rebuild when the platform owns every layout, the editor cannot publish the content model, Core Web Vitals cannot be defended, or you cannot leave with your work.
• Do not change look, URL tree, CMS, and analytics in one weekend. Google Search Central’s site-move guidance is explicit: change one thing at a time.
• Calendar and cash numbers below are planning bands, not invoices and not “average project” statistics.

If this is the loudest symptom	Default job	Smallest honest scope
Looks dated; leads still arrive	Refresh	Type, color, photos, spacing, fold polish
Conversion dropped; stack still fits	Redesign	Fold, IA of key pages, proof, mobile CTA; keep URLs
Theme, CMS, or host is the ceiling	Rebuild	New stack or custom; migration as its own workstream

Buy the job that removes the leak. Do not buy a museum renovation when you needed a storefront.

What do refresh, redesign, and rebuild actually mean?

Teams use these words as synonyms for “make it nicer.” They are three different scopes. If the quote does not name which one you are buying, you are buying fog.

A refresh keeps information architecture, URL tree, CMS, and conversion path. It updates the surface: type, color, spacing, photography, and the first viewport’s polish. The engine stays.

A redesign keeps the platform when the platform still fits. It rewrites composition, page jobs, proof, and often the mobile path. URLs stay unless a page is truly retired. The look changes because the jobs changed, not because someone picked a new theme.

A rebuild replaces the system: stack, content model, templates, often hosting, sometimes the URL tree. That is a production change with a migration, not a Figma file with a new typeface.

Word on the invoice	What must stay	What is allowed to change	What you are not buying
Refresh	URLs, CMS, IA, forms, tracking	Visual system, photos, fold styling, light motion	A new information architecture
Redesign	Stack (if it still fits), domain, most URLs	Page jobs, fold, proof, nav, conversion path	A replatform “included for free”
Rebuild	Brand facts, offer, domain (usually)	Stack, templates, CMS model, sometimes URLs	A weekend theme swap

If a designer says “redesign” and then opens a new Webflow or Framer project with new slugs, that is a rebuild wearing a friendlier noun. Make them say rebuild.

What you heard in the sales call	Translate to	Write on the SOW
“We’ll modernize the brand online”	Unscoped	Refresh, redesign, or rebuild — pick one
“New theme, same Squarespace”	Often a refresh; sometimes a trapped redesign	Name whether IA and forms stay
“We’ll move you to Webflow and clean up URLs”	Rebuild + migration	Two workstreams, two acceptances
“Quick visual pass while we’re in there”	Scope creep	Visual pass is a refresh; “while we’re in there” is how URLs die
“Make it feel more premium”	Not a job	Fold job, proof, CTA, stack — or refuse the meeting

Premium is a result. It is not a scope line.

Conversion drop, visual age, or platform lock — which job is this?

Diagnose from evidence, not from the mood in the kickoff call. Three symptoms get sold the same “we need a new site” sentence. They do not share a scope.

Lindgaard and colleagues showed people form a stable visual-appeal judgment in as little as 50 milliseconds; Nielsen Norman Group treats that snap call as the start of a halo on credibility. Visual age is real. It is not the same problem as a buried tap-to-call on a trade homepage, and it is not the same problem as a Squarespace collection you cannot extend.

Symptom	What you can point at	Default job	Wrong job
Conversion drop	Sessions hold or rise; calls, forms, CRM deals, or checkout fall; fold has no single job; mobile CTA is below the fold or competing with four peers	Redesign (after tracking is proven)	Refresh that only swaps fonts; rebuild that also invents slugs
Visual age	Type, color, stock, and spacing read as a past era; competitors look current; leads still arrive; editor can still publish	Refresh	Rebuild because the homepage bores the founder
CMS / platform lock	Cannot add the collection you need; theme owns every composition; LCP/INP cannot be fixed inside the tool; no clean export; campaigns require a developer for every line of copy	Rebuild	Another premium theme on the same locked CMS
Mixed (two rows true)	Sequence them. Do not merge them into one launch	The leak that stops revenue first	A “full new site” that hides three projects

Run the table left to right. If you cannot fill the “what you can point at” cell with artifacts — screenshots, Search Console, CRM, a failed editor task — you do not have a diagnosis yet. You have a feeling.

A Divine Toke-style shop and an AllCity HVAC-style trade site can share a tired look and still need different jobs. The shop may be locked by a theme that cannot carry product truth. The trade site may only need a phone-first fold. Same complaint (“it looks old”). Different invoice.

Vertical	Looks dated	Conversion drop with a working stack	Platform lock
Local trade	Refresh the brochure chrome; keep tap-to-call	Redesign fold and service pages around call / book	Rebuild if the theme cannot do service-area pages without fifty thin clones
Artist / catalog	Refresh type and stills; keep listen / tour	Redesign home around one release job	Rebuild if dates, merch, or music embeds cannot be fields
Product / shop	Refresh PDP chrome and photography	Redesign collection → product → cart jobs	Rebuild if variants, inventory truth, or checkout cannot live in this CMS
Studio / services	Refresh case-study cards	Redesign proof pages so a skeptic can hire	Rebuild if the CMS cannot hold a real work model

Do not copy a music site’s rebuild into a trade brochure. The symptom table does not care about your industry mood board.

How do you tell which symptom you actually have?

Separate the three with a procedure, not a Pinterest board. Taste is not a measurement method.

1. Export the last 90 days of the business ledger. Calls, form submits that reached a human, calendar bookings, checkout completions. Not sessions. Not “the homepage feels dead.”
2. Export the last 90 days of sessions and landing pages from analytics and Search Console. Note whether traffic moved while the ledger moved.
3. Prove tracking still works on the live templates: complete the conversion in a private window. If the dashboard fell and the ledger did not, you have instrumentation, not a redesign. That diagnostic lives in the conversions-after-redesign spoke; do not start a visual project on a silent tag.
4. Screenshot the fold on a mid-range phone. Can a stranger name the offer and the next tap in five seconds? If no, and the ledger is down, you are in conversion-drop territory.
5. Attempt one real CMS task the business needs this month. New service area, new tour date, new product, new case study. Time it. If the theme fights you or the field does not exist, you are in platform-lock territory.
6. Ask whether you can leave. Export content, CSS, and a URL list. If the honest answer is “we would rebuild anyway,” the lock is already priced in — you just have not admitted it.

Observation	Points to	Next move
Ledger down, DebugView empty	Tracking	Fix tags before design
Ledger down, DebugView healthy, fold is a junk drawer	Conversion / UX	Redesign the jobs
Ledger stable, screenshots look dated	Visual age	Refresh
Ledger stable or down, CMS task fails, no export	Platform lock	Rebuild (stack decision)
Ledger down and CMS fails	Two jobs	Sequence: stop the leak, then replatform

If step 5 fails and step 4 also fails, sequence them. Ship the conversion path on the current stack if it can hold it. Rebuild after the path exists, or rebuild only if the stack cannot host the path at all.

Stop-go checklist before you hire anyone:

• Ledger and sessions pulled for the same window
• One conversion completed in a private window on production
• Fold screenshot on a mid-range phone, not a designer’s Pro Display
• One CMS publish task timed
• Exit/export attempted or explicitly skipped with a reason
• Job named in one word: refresh, redesign, or rebuild
• If two words are true, the sequence is written (which ships first)

No artifact, no project. A kickoff without this list is a taste negotiation.

What does a refresh actually change?

A refresh is a production grade, not a personality transplant. It is the right spend when the site already has page jobs, a CMS someone can use, and a conversion path that still prints money — and the surface is embarrassing next to the brand.

Stay inside this box unless you reopen the diagnosis.

• Type: two families max, display + body, licensed and loaded without blocking the title card
• Color: one accent that means action; kill competing “brand” hues on buttons
• Spacing and rhythm: consistent section padding; stop the template’s random card gaps
• Photography: real work, rooms, merch, crew — not a new pack of stock handshakes
• Fold polish: same job, clearer hierarchy, better crop, still one CTA group
• Motion: light transform / opacity only if LCP already holds
• Components: buttons, forms, nav — restyle, do not re-architect
• URLs, titles, H1 intent, and form destinations: unchanged

In scope for a refresh	Out of scope (that is redesign or rebuild)
Theme tokens, custom CSS, component restyle	New sitemap, new nav model, new CMS types
Replace hero still; keep the same offer line	Rewrite the offer and the conversion path
Tighten mobile type size and tap targets	New stack, new host, new slug tree
Swap dated icons and section chrome	Merge fifty thin pages into a new IA

A refresh that “also” adds a blog, a membership area, and prettier slugs is not a refresh. It is a rebuild that skipped the kickoff. Keep the box honest and the quote stays small.

Lipstick move	Why it fails as a “refresh”	Do this instead
New slider on a fold that already has four CTAs	Motion on a confused job	Cut CTAs; then restyle
Generated atmosphere, same stock faces	Surface still generic	Shoot or crop real work
Custom cursor and grain overlay	Decoration, not hierarchy	Type, spacing, one accent
“Updated” theme with new plugin stack	Silent rebuild	Name the rebuild or refuse
Rewriting every H1 for “freshness”	SEO change dressed as paint	Keep intent; polish presentation

A refresh should still pass a blind test: cover the logo on an interior page and the brand continues. If only the homepage got new makeup, you restyled a landing page. You did not refresh a site.

When is a redesign the right spend?

Redesign when the engine still runs and the composition is the leak. The stack can still host authored layouts. The editor can still publish. The domain and most URLs can stay. What failed is the job of the page: the fold, the proof, the mobile next step, or the path through services.

This is the same standard as the pillar: one fold, one job; proof a skeptic accepts in ten seconds; a CTA that does not require a scavenger hunt. You are not paying to make the old brochure prettier. You are paying to make the brochure do something.

Signal	Redesign fits	Redesign is the wrong spend
Traffic holds; ledger fell; tracking proven	Yes	No — if tracking is unproven, stop
Fold is a chip salad: five CTAs, no title card	Yes	No — if the offer itself is unpriced and untested
Mobile has no tap-to-call / book / listen	Yes	No — if the business does not want inbound
Case studies are adjectives with no names	Yes	No — if there is no work to show yet
Stack can implement the new system	Yes	Rebuild if the theme owns every composition
You want “a new vibe” and leads are fine	No	Refresh, or do nothing

Procedure I use before I write a redesign statement of work:

1. Write the job of the homepage and the two money interior pages in one sentence each.
2. Mark every current section as keep, cut, or move. If everything is “keep,” you do not have a redesign. You have attachment.
3. Lock the URL list. Prettier paths are a migration. They are not a design win.
4. Name the proof assets that exist. If they do not exist, the project is photography and writing, not layout.
5. Confirm the CMS can hold the new components without a platform change. If it cannot, you just found a rebuild.

A redesign that keeps URLs is still a significant change. It is not a site move in Google’s sense. The moment you also change the CMS and the slug tree, you have left redesign and entered rebuild-plus-migration. Say that out loud before you sign.

Page	Job after the redesign	Failure if the job is still fuzzy
Home	One offer, one proof cue, one CTA group	Kitchen-sink services; equal-weight buttons
Primary money page	Specific service / release / product with a next step	About-us prose where a buyer needed a scope
Proof	Named work a skeptic accepts in ten seconds	Adjective pile, logos with no context
Contact / book / listen	Complete the action on a phone	Form below a novel; click-to-call missing
Utility (privacy, 404)	Stay boring and findable	“Brand experience” 404s that hide the nav

Conversion on a brand site is not more CTAs. It is less distance between recognition and action. Recognition comes from craft and specificity. Action comes from a path that works on a warm phone.

When do you rebuild instead of restyle?

Rebuild when the constraint is the system, not the coat of paint. The pillar already draws this line: fold, motion, or proof can be a sprint; rotten IA or stack is a rebuild. This section is the stack half of that line.

Rebuild if most of these are true:

• The theme, not you, decides every composition
• You cannot add a collection, SKU field, tour date, or location without a plugin pile
• Largest Contentful Paint or Interaction to Next Paint cannot be brought into Core Web Vitals “good” on a mid-range phone inside this tool
• There is no export that includes CMS content — Framer’s missing HTML export and Webflow’s CMS-less code export are the classic versions of this trap
• Campaigns wait on a developer for copy that should be a field
• Ownership of domain, DNS, and the CMS login is unclear or lives in a freelancer’s account
• The IA is a junk drawer: fifty thin pages, no jobs, no way to trim inside the current model

Constraint	Refresh / redesign can absorb it	Rebuild is the honest call
Dated type and photos	Yes	No
Weak fold, stack is flexible	Redesign	Only if templates cannot change
Collection model is the product	Rarely	Yes
Performance ceiling is the vendor’s	Temporary hacks only	Yes
You will migrate in 12 months anyway	Do not refresh into a cliff	Rebuild once, on purpose
DIY builder still matching the stage	Stay; see hire vs DIY	Not yet

If the site is still a validation URL — offer changing monthly, pre-revenue, DIY nights cheaper than a studio — do not rebuild. Stay on the builder until the site has to earn customers. That decision is hire a designer vs a DIY builder, not this table.

A rebuild without a stack decision is a mood. Pick Framer, Webflow, or custom with Framer vs Webflow vs custom before you mood-board the new look. The look is scene two.

Sequence a rebuild like production, not like a rebrand film:

1. Ownership. Domain, DNS, CMS, analytics, Search Console in the company’s name.
2. Content model. Types, fields, who edits, what cannot be a blob of rich text.
3. URL policy. Keep, map, or retire — written before templates.
4. Stack choice. Framer vs Webflow vs custom from constraints, not from last month’s awards.
5. Templates and fold. Authored layouts on the chosen engine.
6. Cutover. Tags, redirects if any, robots, sitemap — as their own checklist.

Skip this order	What you get
Look before model	Pretty pages the editor cannot fill
Stack before ownership	A beautiful site in someone else’s login
Slugs before inventory	A migration you pretended was design
Cutover as “the last afternoon”	Silent tags and leftover noindex

Failure mode: look, URLs, CMS, and tracking in one launch

What breaks: you ship a “redesign” that is also a replatform, also a slug rewrite, also a new cookie banner, also a new form endpoint. Rankings wobble. GA4 key events go quiet. The founder blames the typeface. The designer blames Google. Nobody can isolate the cause because four systems moved at once.

Google’s site-move document is the receipt, not a vibe: if you want a new domain, a new CMS, and a new layout, do them one after the other, not in a single cutover. For URL changes on a medium site, Google says it can take a few weeks or more for new URLs to replace old ones in results — that is Google’s processing window, not a studio calendar I invented.

Combined in one weekend	What you can no longer tell	Cost you actually pay
New look + new slugs	Design vs redirect map	Organic cliff blamed on “the redesign”
New CMS + new tags	UX vs instrumentation	Phantom conversion drop
New host + leftover noindex / staging robots	Crawl vs craft	Pages disappear from the index
New forms + new thank-you URL	Offer vs measurement	CRM empty, ads still spend
All of the above	Anything	You fund a forensic project after you already funded the launch

Procedure if you already mixed them:

1. Freeze visual tweaks. You do not have a taste debate until measurement is back.
2. Prove the Google tag, the live event name, and the key-event toggle on the new templates.
3. Diff the URL inventory: crawl the live site against the pre-launch list. Every miss needs a 301 or an honest 404.
4. Confirm Search Console property, sitemap, and robots.txt are production, not staging.
5. Chart the business ledger next to sessions. Only then reopen composition.

Bravery is not a restore strategy. Isolation is.

Change	Google’s category	What you owe
New CSS/type on the same URLs	Not a site move	Performance and tracking still work
New layout, same URLs, same CMS	Still not a URL move	Titles/H1 intent stable unless the job changed
New CMS, same URLs	Platform change; treat cutover as production	Parity on canonicals, robots, templates, tags
New URL paths or domain	Site move with URL changes	301 map, Search Console, patience through recrawl
Layout + CMS + URL tree together	The failure mode in this section	Split the launch or budget the forensic

Same-URL redesigns still break when staging noindex ships, when the thank-you URL moves, or when the cookie banner starts blocking tags. Those are cutover bugs. They are not proof that “redesigns always tank conversion.”

How do you confirm the CMS or platform is actually the lock?

“We have outgrown Squarespace” is a slogan. Prove the lock with failed tasks, not with a competitor’s Framer site.

Run this confirmation before you budget a rebuild:

1. List three content types you must publish in the next quarter. If the CMS has fields for them today, you are not locked on content model.
2. Publish one of them yourself, timed. If a non-developer cannot do it in a sitting, the lock is editorial, which may still be a rebuild if campaigns cannot wait.
3. Attempt the performance floor. Field LCP and INP on a mid-range Android, not desktop Wi-Fi Lighthouse. If the only remaining wins are “delete the theme,” the lock is performance.
4. Attempt an exit drill. Export pages, CMS rows, and assets. Write down what you would not get. That list is the rebuild’s hidden scope.
5. Check account ownership. Domain registrar, DNS, CMS, analytics, Search Console — all in the company’s name. A lock that is actually a freelancer’s login is a paperwork problem first.

Test	Pass (not a platform lock)	Fail (rebuild is on the table)
New collection / type	Exists or can be added in-product	Requires a new platform
Editor publishes without a developer	Yes, this week	No, every campaign is a ticket
Mid-range phone LCP	In “good” or fixable with media discipline	Theme scripts make it unreachable
Export	Content + structure you could rebuild from	Theme soup; CMS stays behind
Ownership	Company owns every login	Access lives in a personal inbox

Squarespace, Wix, WordPress-with-a-rented-theme, Webflow, and Framer all produce this failure in different costumes. The costume does not matter. The failed test does. If every row passes and you still hate the look, you wanted a refresh and dressed it up as destiny.

Costume	Sounds like lock	Often is not lock	Often is lock
Squarespace / Wix	“We’ve outgrown it”	You never learned the editor; the offer is unclear	Collections, performance, or exit cannot meet the next year
WordPress + marketplace theme	“We need custom”	Plugins fighting each other; nobody owns updates	Theme owns templates; you cannot implement the fold
Webflow	“CMS is limiting”	Nested collections you have not modeled	Editor cannot publish without a designer on every page
Framer	“We need code”	Marketing site that wanted a product	You need an exit or a system Framer will not host
Custom already	“Rebuild again”	No design system; entropy across pages	The app/CMS split is wrong; start from the model

Hate is not a failed test. Failed publish, failed export, and failed field LCP are.

What are the planning bands for cash and calendar?

Treat every range in this section as a planning band: a starting envelope for scoping, dated to August 2026 market guides where I cite them, not Spurlock Studios pricing, not a promise of week counts, not a survey mean. If a vendor quotes outside the band, ask which job they are actually selling.

WebFX’s 2026 web-design pricing page reports average design spend from about $1,000 to $30,000+, with larger work sometimes clearing $100,000. OuterBox’s 2026 cost guide puts many custom business and lead-generation sites in a $10,000 to $50,000+ planning band. Those are market shapes. They are not your invoice.

Job	Calendar planning band (not a statistic)	Cash planning band (market shape, not SS rates)	What the band assumes
Refresh, stack owned, assets exist	Days to a few weeks	Low thousands of hired labor, or your own hours on DIY	No new IA, no migration
Redesign, same stack, URLs held	Several weeks to a couple of months	Often four figures into five for serious custom craft	Proof assets exist; no replatform
Rebuild, new stack, URLs held	A couple of months and up	Five figures is where “serious custom” usually starts in those guides	Content model + templates + QA
Rebuild plus URL / domain move	Longer than the rebuild alone	Rebuild band plus redirect mapping, crawl, Search Console watch	Google may take a few weeks or more to show new URLs on a medium site

Do not turn the calendar column into a Gantt promise. Editorial delays, photography, legal, and DNS are not in the band. A refresh with no photos is not a refresh. It is a waiting room.

• Every number in the SOW is labeled “planning band” or “fixed quote”
• URL migration is a separate line, not buried under “design”
• Tracking cutover is a separate line
• Photography and copy are either in scope or explicitly out
• You have a rollback path that is not “restore from vibe”

If the quote is one lump called “new website,” you cannot tell refresh from rebuild. Split it or walk.

Not in the planning band — price these as extras or as blockers:

• Photography direction and a shoot day
• Copy for money pages (not lorem, not “we’ll pull from the old site”)
• Redirect map and QA crawl if any URL changes
• Consent banner + GA4/GTM rebuild
• DNS, email, and Search Console verification that survive cutover
• Training the actual editor, not the founder who never logs in
• Accessibility pass (keyboard, contrast, reduced-motion) as craft, not a plugin

A cheap refresh that skips photos is still a cheap refresh of a dated brand. The band assumed assets exist. If they do not, you are in a content project wearing a design costume.

What should you ask a designer about this?

Ask questions that force a job name. If the answers are adjectives, you do not have a partner yet. You have a mood board with a rate.

• Which job are we buying: refresh, redesign, or rebuild? Say the word.
• What stays: URLs, CMS, tracking, hosting? Write the list.
• What is the diagnostic artifact — ledger, CMS test, or screenshot — that picked this job?
• If conversion is the reason, how will we prove tags before we judge the fold?
• If platform lock is the reason, which failed test proved it?
• Who owns domain, DNS, CMS, analytics, and Search Console on the last day?
• What does a “done” page look like on a mid-range phone: offer, proof, one CTA?
• What is explicitly out of scope so this cannot silently become a migration?

Question	Acceptable answer	Walk-away answer
Which job?	One word from the table, with a why	“A bit of everything”
URLs?	Inventory + keep/change map	“We’ll clean them up in Webflow”
Stack?	Named, with exit notes	“We’ll decide in Figma”
Success?	Ledger metric + field CWV, dated	“It will feel premium”
Rollback?	Named backup and DNS hold	“We only go forward”

Who should even be in the room is a different spoke. If you are still validating the offer, stay DIY and do not hire a rebuild. If you already know the site must earn the next ninety days, hire for the job you named — not for a portfolio piece that ignores the CMS.

Handoff questions (get answers in writing):

• Logins: registrar, DNS, CMS, hosting, analytics, ads, Search Console
• Where the source lives: theme customizer, Webflow account, Framer project, git repo
• Who can publish after week two without a studio Slack
• What happens if you fire each other — files, licenses, font files, stock licenses
• Staging URL policy so noindex cannot ride to production
• Form destinations and spam rules on production, not on the designer’s test inbox

If they cannot answer ownership, they cannot answer rebuild. Refresh might still be possible. Rebuild is how you lose the domain in a personal Gmail.

When is a custom site worth it for this?

Custom is worth it when the rebuild is already the honest job and a builder cannot host the system without fighting you. Custom is not worth it as a status upgrade on a brochure that needed type and a tap-to-call.

Use the stack chooser in Framer vs Webflow vs custom as the mechanism. This table is only the “is custom the rebuild target” slice.

Situation	Custom is in play	Custom is theater
Unusual interactions, strict performance, integrations builders fight	Yes	No
Marketing site, designer-owned motion, campaigns this month	Framer may win	Custom as ego
Collections edited weekly by non-developers	Webflow may win	Custom with no editor
You cannot export and you know you will leave	Yes, with an exit plan	Another closed builder
Offer still changing; site is a confirmation URL	No	Five figures for a moving target
Visual age only; CMS is fine	No — refresh	Custom because Awwwards

Checklist before you greenlight custom as the rebuild:

• Platform-lock tests failed, or the interaction model is actually a product
• Someone on your side will own git, hosting, and the CMS after launch
• Money pages and the fold have jobs written down
• Migration (if any) is sequenced after or separately from layout
• You are not using “custom” to avoid saying “we have no photos”

Authored beats rented. Custom CSS on a generic card grid is still a template. A rebuilt builder site with real work and a locked type system can still feel like a film. Pay for authorship, not for the word custom.

Three-year lens (planning, not a forecast)	Builder refresh / redesign	Custom rebuild
Month-one cash	Lower if the stack stays	Higher labor up front
Rent	Platform plan continues	Hosting you choose; still not free
Change cost	Theme fights unusual pages	You own the templates — if you keep an owner
Exit	Often a future rebuild anyway	Git + CMS export if you designed for it
Failure cost	Cheap to abandon if the offer dies	Expensive souvenir if the offer was never real

Compare three-year ownership, not month-one sticker shock. That is the same argument as the five-figure custom spoke, applied to this decision: do not buy custom to avoid saying the offer is unfinished.

What should you skip if you only have a week?

Skip the identity crisis. A week is a triage, not a rebuild. You can name the leak, patch the conversion path, and schedule the real job. You cannot honestly replatform, rewrite the sitemap, and reshoot the brand in five business days without lying to yourself.

Do this, in order:

1. Day 1 — Diagnose with the symptom table. Ledger vs sessions vs CMS test vs fold screenshot. Write one sentence: refresh, redesign, or rebuild.
2. Day 1 — Prove the form, phone, and analytics fire. If they do not, that is the week. Stop.
3. Day 2 — Fold only. One headline, one support line, one CTA group, one visual. Kill competing buttons.
4. Day 3 — Mobile next step. Tap-to-call for trades, listen/tour for artists, short form for studio work. Test on a real phone.
5. Day 4 — Proof. Put one named piece of work or one specific constraint above the fold or immediately under it. No adjective pile.
6. Day 5 — Decide the follow-on job and what is not in it. Book photography, stack choice, or a sprint. Do not start a new theme.

In a one-week window	After the week
Tracking proof	Redesign of interior IA
Fold job and mobile CTA	Rebuild / replatform
Kill dead nav items	New CMS model
Compress hero media	Custom motion system
Write the job name on the SOW	Execute that SOW

If the honest job is rebuild, the week’s output is a stack decision and a URL inventory, not a new homepage in a trial account. Shipping a trial theme as “the redesign” is how you pay twice.

Do not open these in a five-day window:

• A second domain “just to test”
• A new slug taxonomy because the old one “looks ugly”
• A motion library on a fold that still has four buttons
• A CMS migration spreadsheet you will not finish
• A brand workshop that postpones the phone number on the fold
• A cookie-banner redesign that nobody tests on decline

Triage ships the next tap. Identity work that blocks the tap is how a week becomes a quarter.

How do you measure whether the choice is working?

Measure the thing the job was hired to fix. A refresh that “raises brand perception” with no screenshot test is unfalsifiable. A redesign judged on sessions is the wrong scoreboard. A rebuild judged on Dribbble likes is a costume party.

Job you bought	Primary scoreboard	Secondary	Do not use as the verdict
Refresh	Five-second fold screenshot test with people who do not work for you; “does this look current next to two competitors”	Field LCP still in “good”	Raw session count
Redesign	Business ledger: calls, qualified forms, bookings, checkout — same definitions as pre-launch	Mobile completion of the primary CTA	Vanity bounce rate
Rebuild	Editor can publish the new types without a ticket; exit drill still works; CWV on mid-range phones	Rankings after Google has recrawled — wait through Google’s “few weeks or more” window on URL changes	Launch-week branded-search panic

Procedure at 14 and 28 days (planning checkpoints, not a universal “results by day 14” claim):

1. Re-run the conversion in a private window. Tags still fire.
2. Diff the ledger against the same weekday mix as baseline. One week of noise is not a verdict.
3. Re-screenshot the fold on the same phone class.
4. For rebuilds with URL changes, watch Search Console coverage and the sitemap, not just the design Figma.

If the ledger is flat after a refresh, you bought the wrong job — or the offer is the leak and no website will save it. If the ledger is flat after a redesign and tracking is clean, look at the offer and the traffic quality before you commission a rebuild. Sites do not invent demand. They either collect it or spill it.

Confounder	Looks like a failed redesign	What it actually is
Seasonality (HVAC, tax, tour cycles)	“The new site killed leads”	Compare YoY or like weeks, not launch week vs peak
Paid landing URL changed	CPA spiked	Ads pointed at a 404 or a new slug
Offer / price changed in the same sprint	Conversion rate moved	Two experiments, one narrative
Sales follow-up died	Forms “stopped working”	CRM full, humans slow
Consent default tightened	Key events down, ledger flat	Measurement, not UX

Write the confounders down before launch. Otherwise every dip becomes a reason to rebuild the thing you just rebuilt.

FAQ

Redesign vs refresh vs rebuild — which do I need?

Match the job to the symptom. Visual age on a working CMS is a refresh. Conversion drop on a stack that can still host authored layouts is a redesign. CMS or platform lock — failed editor tasks, no exit, performance you cannot fix inside the tool — is a rebuild. If two symptoms are true, sequence them; do not merge them into one launch.

How do I measure whether the refresh, redesign, or rebuild is working?

Use the scoreboard the job was hired to move. Refresh: whether strangers read the fold as current and LCP did not regress. Redesign: the business ledger, not sessions. Rebuild: editors can publish, you still own an exit, and field Core Web Vitals hold. Launch week is noise; compare like weekdays and prove tags still fire.

What usually fails first when teams try this?

Isolation. Teams change the look, the slugs, the CMS, and the tags together, then argue about type while Search Console and GA4 go quiet. Google tells you to change one thing at a time on a site move. The other early failure is treating a tracking outage as a design problem.

How long does this take to show results?

There is no honest universal week count. Use planning bands: a refresh can show a visual change as soon as it ships; a redesign shows on the ledger after you have comparable days and clean tracking; a rebuild with URL changes also waits on Google’s recrawl, which Google describes as a few weeks or more for many medium sites. Anyone selling a guaranteed ranking date is inventing a statistic.

What should I skip if I only have a week?

Skip the replatform, the new sitemap, and the identity rewrite. Spend the week on diagnosis, tracking proof, the fold job, and the mobile CTA, then write down the follow-on job. A week can name a rebuild. It cannot honestly finish one.

When is this not worth doing yet?

Do not refresh, redesign, or rebuild if the offer is still changing weekly, you are pre-revenue, or no one will maintain a CMS. Stay on a DIY builder until the site has to earn customers. Also wait if tracking is broken — you cannot choose a job from a dark dashboard.

CTA

Name the leak, then buy the smallest job that removes it — refresh, redesign, or rebuild, not a vague “new site.”

Websites · Start a websites sprint