Plan My Website Rebuild and Launch

Insivia buyer-centric website playbook · P12 · Version 0.7.1

Insivia's position

A rebuild that removes the explanation a buyer needs has made the website worse. A better-looking template does not make up for it.

Your team has seen the strategy, sitemap, prototypes, and product explanations for months. The buyer has not. They might arrive through an old article, a campaign link, or a colleague's bookmark. They still need to understand the offer, judge its relevance and limits, inspect evidence, and choose a useful next step.

Carry those buyer requirements into production and release decisions. When scope gets tight, simplify how you deliver the answer before deleting the answer itself. A clear table may serve the buyer while the custom animation waits.

Design approval, working-build checks, and live verification establish different things. Keep each claim tied to its evidence. A launch date does not resolve an open defect.

Purpose and boundaries

Decision: What can we rebuild and release while preserving the buyer's ability to understand, evaluate, and act?

Use this after buyer strategy and page responsibilities are established. P01 owns that strategy. P12 turns it into a phased workplan, URL decisions, acceptance checks, and release/recovery responsibilities. The essential exercises, examples, and AI rules are in this download; other playbooks are optional handoffs.

First output: Only the requested decision or artifact. Use a workplan or URL table when that is the task; expand the runbook only when requested. Preparing a plan does not execute a redirect, deploy a change, run a test, or authorize launch. Do not choose a new platform or redesign the entire site to answer a narrow delivery question.

AI starting rule: Use this file for the method and the user's brief for project facts. Answer the bounded task when sufficient facts are supplied. If missing buyer strategy or scope prevents the requested plan, ask up to three focused questions and stop. Never fill gaps from fictional examples. Detailed response modes below apply to the whole file.

Buyer psychology: preserve the judgment behind the requirement

Buyers bring different knowledge, pains, interests, motivations, and buying factors. Record what is supplied and its source. An industry expert may still need the basic explanation of your particular offer. A returning evaluator may want one requirement immediately, without another introduction.

Project familiarity hides these gaps. Employees fill in meaning, know where the answer moved, and remember material that never made it into the build. Buyers cannot use information that exists only in your team's heads.

Trace the actual journey in scope: where the buyer enters, what they need to understand, what evidence or requirement they need to inspect, and what they may choose next. Do not assume everyone enters through the homepage or follows a compulsory funnel. Preserve useful old entry routes and recognizable destination labels where the evidence supports them.

Confidence should rest on accurate understanding. A buyer who understands a real limitation and rules you out has made an informed decision. Do not turn that correct no-fit into a failed acceptance test or a demand for more persuasion. A buyer who likes a false promise has not validated the promise.

Freeze the project facts

Input	Record
Buyer and decision	Situation, entry context, prior knowledge, pain or desired progress, motivation, buying factors, fixed requirements, next decision; source and unknowns.
Release scope	Named pages, components, or journeys; what is changing and staying; actual platform, domain, URL, access, schedule, and data constraints where supplied.
Truth and available material	Verified capabilities/limits, approved content facts, actual assets and working routes. Separate available, planned, and unknown.
Current state	Production versus staging/local; exact URLs and captures; actual task responses, technical checks, search and analytics evidence with dates and limits.
Responsibilities	Confirmed owners/authority and dependencies. An unassigned role stays unassigned. A proposed role is not an appointment.

Missing search evidence is unknown, not zero value. Missing operational facts are owner questions, not permission to invent a process. A fixed platform or URL is a constraint to preserve unless the user explicitly changes it. A requirement to preserve /pricing does not establish that an unspecified draft is the pricing page.

Exercise: decide what the buyer can afford to lose

Start with the buyer question, not the component somebody wants to cut.

1. State the buyer decision and the answer needed for it. Record the evidence, or label the need as a hypothesis.
2. Name what the company proposes removing, moving, shortening, or delaying.
3. Explain what the buyer would lose: understanding, a fit answer, relevant evidence, access, or completion of a real commitment. Do not invent a psychological cause.
4. Classify the consequence: an established blocker; an important but recoverable gap with a supported alternative; or an enhancement that can wait. Unknown impact remains open for a check. Do not label every preference critical.
5. Compare feasible, truthful options using the supplied constraints. Reuse a working route, simplify the representation, release a smaller scope, or defer the affected work. Check whether an existing asset or simpler representation serves the same job before adding production work. Planned assets are not available assets.
6. Record one neutral acceptance check and what would change the decision.

Buyer requirement/source	Decision affected and consequence	Minimum truthful delivery	Dependency/state	Acceptance evidence and environment	Release effect and responsibility
[Actual question; evidence or hypothesis]	[Why its loss matters; fixed requirement if supplied]	[Supported representation or existing route]	[Known, missing, ready, or deferred]	[Proposed check versus recorded result]	[Block affected scope, conditionally release, or follow up; owner confirmed/unassigned]

Use the five-part buyer decision record for the priority tradeoff: buyer starting point → company assumption → interpretation with evidence/uncertainty → decision and credible alternative → check and reversal. A credible alternative must respect current product truth and fixed buyer requirements. Do not fill the record repeatedly for every minor task.

Build a phased workplan

Choose tasks relevant to the actual release. Keep dependencies explicit; leave dates and names blank when unknown.

Phase	Required work	Evidence to move forward	Responsibility to confirm
1. Strategy handoff and scope	Freeze the buyer decisions, ranked requirements, affected journeys, and fixed constraints.	An inspectable requirement record. Unknown strategy requires focused questions, not an invented production plan.	Strategy/project role; assignment unconfirmed unless supplied.
2. Content, facts, and URL decisions	Verify claims and assets; decide what useful substance survives; prepare relevant URL dispositions and internal-link changes.	Source facts, actual asset availability, proposed mappings and destination readiness. Correct known false claims immediately.	Content and relevant technical/search roles.
3. Build the minimum useful experience	Implement the agreed content, routes, and behavior in the working build. Reuse what works; defer enhancements that do not carry essential answers.	Build capture/version and completed implementation records. Completion alone is not acceptance.	Implementer/editor roles.
4. Pre-release acceptance	Check the buyer tasks and the technical behavior that can be tested before deployment. Classify defects and unresolved dependencies.	Recorded results in the stated environment; release-blocking gaps resolved or affected scope withheld.	Appropriate verifier and release decision-maker.
5. Controlled release and recovery preparation	Confirm what will change, authorization, production-only checks, response responsibilities, and a feasible recovery method.	Technical owner confirms deployment/recovery constraints, including live data that must survive. This is readiness to deploy, not proof of production behavior.	Confirmed release/technical authority.
6. Live acceptance and follow-up	Verify the deployed journey, final URLs, claims, receipt of submissions, and relevant crawl/measurement behavior. Observe later outcomes separately.	Actual live results; failures lead to the agreed correction, withdrawal, or recovery decision. Track remaining issues without declaring them fixed.	Live verifier and response owner.

Do not demand that a new production page be verified before it has been deployed. Test what you can before release, then plan a controlled live check and response. Do not call an untested production journey accepted because staging passed.

Make URL decisions that preserve useful intent

Separate the content decision from the URL response. Merging two articles does not by itself establish where either URL should go.

1. Record the actual old URL and its buyer question, useful substance, known incoming routes, and search evidence or unknowns.
2. Decide keep, rewrite, merge, move, retire, or create. Rewriting a page does not require changing its address.
3. For a permanent move, identify an actual relevant replacement and its readiness. It may use a different format; it must meaningfully answer the old need. A shared broad topic is insufficient.
4. Where suitable content has been consolidated, multiple old URLs can point to that ready destination using appropriate permanent redirects. Update internal links to the final destination and test the real response chain. Preserve supplied approval boundaries.
5. When genuinely removed content has no suitable replacement, propose retirement with an appropriate 404 or 410 response. Do not invent a destination or send it to the homepage. A useful error page can offer onward links without making an unrelated redirect appropriate.
6. A useful archive retained for an established purpose can remain a normal page. Distinguish that 200 archival page from a retired resource or an error page incorrectly returning success.

No known links or traffic does not make an irrelevant redirect relevant. Unavailable Search Console data does not stop every planning decision. Use supplied buyer/content facts, record uncertainty, and prioritize the missing evidence that could change the proposed disposition. Do not guarantee unchanged rankings.

Worked URL table — fictional, exact addresses

These are invented relative paths, not Insivia redirects or verified client URLs. In this scenario, the owner has confirmed that the replacement is published, returns 200, and preserves both articles' worked explanations and informational purpose. Search/link metrics are unavailable. All actions below are proposals; no redirect or removal has run.

Current URL	Supplied job/value	Proposed disposition and destination	Necessary check
/articles/reporting-a/	Monthly-reporting explanation; repetitive, useful worked detail	Merge; proposed permanent redirect to /resources/monthly-reporting/.	Confirm relevant content and final target; verify response and internal links when implemented. Metrics remain unknown.
/articles/reporting-b/	Same informational job with overlapping explanation	Merge; same relevant replacement /resources/monthly-reporting/.	Same content/route checks; consolidation permits a shared meaningful destination.
/requirements/	Buyer-critical fit answer; traffic unknown	Keep its address and useful explanation. Preserve a findable route from relevant pages.	Check factual currency and actual findability. Unknown traffic is not proof of low importance.
/pricing/	Address is fixed by the supplied project scope	Keep the URL. Review only the changes actually in scope.	Confirm it remains reachable; do not invent a move or assign an unrelated draft to it.
/events/workshop-2019/	Owner-confirmed obsolete event; no equivalent replacement	Propose retirement with 404 or 410; destination: none.	Confirm removal decision and any remaining content/reference obligation; verify the chosen response. Do not manufacture a current event or homepage replacement.
/industry/healthcare/	A sector requirement the proposed generic service page does not answer	Keep the current page. The generic page is not a suitable replacement.	Verify the retained answer and route. A later scoped replacement would need its own content and readiness evidence.

URL worksheet field	What to record
Current URL and job	Supplied address and question it answers; no invented paths.
Evidence and constraints	Buyer/search/link value, fixed address requirements, source/date, unknowns.
Content disposition	Keep, rewrite, merge, move, retire, or create; explain what substance survives.
URL response/destination	Unchanged address, proposed permanent redirect with relevant target, or proposed retirement with no target. A new page's unassigned URL stays unassigned.
Readiness and verification	Available versus proposed destination; dependencies; planned tests versus actual responses.

Separate acceptance, release, and recovery decisions

Use this table for the affected scope. Record each check's environment, verifier, source, date/version, and actual result. Mark unrun tests not run, rather than pass.

Area	Before controlled release	Verify on the live release	Decision when unresolved
Buyer understanding and fit	Neutral tasks in a representative working build: explain the offer, find the needed answer, judge fit. Keep researcher expectations out of participant wording.	Confirm the deployed content and routes match what was tested; investigate observed differences.	Withhold or simplify the affected scope if a necessary answer is lost. Correct no-fit is not confusion.
Content truth and availability	Check capabilities, limitations, proof, process facts, and real versus unbuilt assets.	Confirm no false promise, placeholder, unavailable tool, or wrong destination has shipped.	Narrow or remove unsupported claims. Preference, approval, or a deadline cannot substantiate them.
Access and working journeys	Test relevant responsive/keyboard behavior, labels, errors, confirmations, and integrations where accessible.	Verify the actual live path, including receipt/routing/storage of an authorized test submission when in scope.	A screenshot of a thank-you page does not prove delivery. An alternate test endpoint does not establish the actual live route works. Record any test restrictions and the resulting limit.
URL and crawl continuity	Review mappings, final targets, planned statuses, internal links, intended indexing, canonicals, and sitemap changes where relevant.	Check deployed responses, final content, links, crawl settings, and relevant measurement events.	Fix a consequential broken route or withhold its affected change. A 200 alone does not establish relevance, indexing, or ranking preservation.
Recovery and live records	Confirm a feasible technical response and what current content/data must survive it.	Use the agreed correction/recovery path if live acceptance fails; verify the restored journey and preserved records.	A backup's existence is not a recovery test. Do not assume a full database restore is safe or permitted.

Keep appropriate specialist checks. A quick keyboard/form review or automated scan is not comprehensive accessibility verification. Use actual project requirements; do not invent a legal approval process or claim compliance from screenshots.

Separate release blockers from enhancements. An unresolved required submission path, misleading claim, or lost fit answer may block the affected release. A decorative animation can often wait when the buyer's job is already served. Missing measurement or other gaps need an explicit consequence and decision, not an automatic whole-site stop or an automatic pass.

Recovery must preserve current truth and relevant new live records. Respect a supplied prohibition on full database overwrites. Have the technical owner confirm what can be safely reversed or corrected; do not prescribe a backup/restore method without knowing how data and content are stored. A recovery plan must not knowingly restore a false claim. Fixed scope stays fixed.

Completed delivery example — fictional and unbranded

All facts, observations, and statuses here are invented for teaching. They are not client findings, actual tests, or BuyerTwin results. Do not reuse them as another business's facts.

Scope and buyer: An existing WordPress service-page rebuild keeps the domain and current /pricing/ address. Unfamiliar operations managers need to understand the monthly-reporting service output and find requirements before deciding whether to inquire. The current /requirements/ page is available and its facts are owner-confirmed. The affected service-page URL has not been supplied; do not invent it.

Company preference: The team wants to remove the worked explanation and direct requirements route to finish an animation. Its design has been approved. In supplied teaching observations, two unfamiliar readers could not find the required answer in staging. A simple factual text/table explanation and the existing requirements link are feasible.

Operational facts: Only screenshots/local previews have been reviewed technically. No live submission-delivery check has run. New production submissions exist since an old backup. Full database overwrite is prohibited; a safe recovery method is unconfirmed.

Compare credible release choices

Choice	Buyer consequence	Delivery consequence and decision
Restore the plain explanation and existing requirements route; defer animation	Preserves the answer the buyer needs using known facts and available material.	Preferred minimum build, conditional on pre-release checks and a confirmed safe deployment/recovery process. No new calculator, sample file, or platform is needed.
Keep the existing live journey while deferring only the affected rebuilt page	Avoids replacing a functioning route with an unaccepted one.	Credible alternative if the minimum build or recovery preparation cannot be completed. Confirm technical feasibility; do not claim a partial release is already supported.
Delay the planned release	Leaves the current live experience in place while known blockers are addressed.	Appropriate if the affected scope cannot be isolated safely. Costs schedule progress; avoids pretending approval resolved the gap.

Completed phase record

Phase	Workplan entry	Supplied status or next evidence	Responsibility
Handoff	Protect offer explanation and requirements access; preserve WordPress/domain and fixed address.	Buyer task and constraints supplied.	Strategy/release roles; named people unassigned.
Content/URLs	Use verified text/table and existing requirements destination; review only actual URL changes.	Feasible inputs supplied. No service URL or redirect rule supplied.	Content/technical roles proposed, not appointed.
Build	Restore the explanation and link in staging; defer animation.	Proposed work, not completed.	Implementer unassigned.
Pre-release checks	Ask an unfamiliar reader to explain the offer and find the answer without hints; check relevant working behavior and recovery feasibility.	Earlier staging failure supplied; revised version untested. Screenshot approval does not close the gate.	Appropriate verifiers unassigned.
Controlled release	Use a confirmed method preserving new live records; withhold affected work if this cannot be established.	Recovery method unknown. Full database overwrite is excluded.	Technical/release authority must be confirmed.
Live acceptance	Verify deployed explanation/link and the real submission path; record results and use agreed response if necessary.	Planned after controlled deployment, not a completed result or an impossible pre-deployment requirement.	Live verifier/response owner unassigned.

Priority decision: Hold the affected release for the minimum content/route fix and necessary pre-release/recovery checks. If those cannot be satisfied, preserve the existing working journey or defer the release. The company changes what it treats as essential; buyer judgment outranks animation completion.

Buyer decision record: Starting point: an unfamiliar evaluator needs the output and fit answer. Company assumption: design approval makes the page ready. Interpretation/evidence: supplied staging readers could not find the answer; no inference about all visitors or conversion rate follows. Decision/alternative: minimum truthful explanation and existing route, or retain/defer affected scope. Check/reversal: use a neutral working-build task and actual live verification; reconsider the representation if readers still cannot judge the offer. Never reverse a truth or data constraint because a deadline approaches.

No phase above claims a launch or a redirect has occurred. The completed artifact is a decision-ready plan with open gates, not a fictional success report.

Applying this playbook with your AI

Shared rules for facts, resources, and response scope

Use Insivia's method; use the user's facts. This file supplies a buyer-centric method. Its fictional examples supply no facts about another business. Similar subject matter does not make their features, prices, roles, assets, constraints, or findings applicable. Use supplied business facts and sources actually inspected for this task. A faithful paraphrase or task-level explanation is useful only when those facts support it. Do not add formats, fields, controls, outcomes, approvals, or process steps because they seem likely.

Keep each item's status intact. Available, approved, proposed, feasible, incomplete, and unknown mean different things. Feasible does not establish a draft. Incomplete does not establish that work never started. An available destination does not establish a built link, accessible contents, booking, or a response service. Name the exact item when recording status. Unknown is not confirmed absence. Reuse an existing approved answer when it serves the buyer; proposed resources remain unavailable. Respect explicit publication and source-use restrictions, including prohibitions on deriving examples from restricted material.

Answer the requested task, then stop. The user's requested count, format, and shorter length control the answer. One sentence, one table, or one decision does not trigger a full plan, worksheet, validation kit, or closing offer. For copy-only requests, return copy only. For a factual correction, preserve the verified capability wording; add no new capability, purpose, benefit, route, or promise. Correct the affected claim without expanding to unrelated work. Never retain a known false claim as an alternative or wait for a future feature to substantiate it.

Ask only for facts that could change this decision. If essential buyer context is missing for strategic work, ask at most three focused questions and stop. Do not block a narrow correction with irrelevant intake questions. A known buyer question with an unknown business answer is an owner gap, not permission to invent an answer. A verified incompatibility with a fixed buyer requirement warrants a clear no-fit finding; do not invent a workaround or reopen that requirement under company pressure.

Connect the recommendation to the actual buyer. Use their supplied prior knowledge, pain, motivation, buying factors and next decision. Possible interpretations are hypotheses, not observed reactions. Do not invent a company preference, psychological motive, alternative or conflict to fill a reasoning template. No change can be the supported conclusion. For a fuller review, make the buyer reason and consequential company choice explicit without repeating the same record for every row.

Represent inspection and tests honestly. Supplied notes are not direct inspection. A URL alone does not establish that it was read. Text cannot establish visual quality, interactions, or delivery. Proposed checks have not run. Keep neutral questions free of expected answers and unsupported steps. Generic AI role-play is not human research or BuyerTwin analysis. Attribute Insivia in explanatory output, outside proposed public copy; exact copy-only output needs no added attribution.

Keep the first response proportionate. Default to one priority decision and its buyer reason within 220 words. Expand only for a requested artifact or detail. Use the task guidance below conditionally; worksheets, examples and full workflows are reference resources, not a requirement to reproduce them all.

Task-specific application

Use only the requested scope. Proposed explanations remain proposed; component and environment statuses remain unknown unless supplied. Preserve actual platform, URL and live-data constraints without importing example constraints. Separate pre-release checks, controlled deployment and later live acceptance. Use exact relevant supplied URL targets; genuine retirement may have no target, with appropriate 404/410. Unknown search data is not zero or a universal stop. Do not invent an enhancement or competing design preference to justify a plan. Retain/defer current scope when no smaller supported release exists. Fixed routes and constraints are settled inputs: preserve them without asking the user to confirm them again. Do not add an approval requirement that the project has not supplied. Name only the evidence needed for the requested decision. For a short workplan, use brief clauses in each cell; preserve material constraints without repeating the brief or explaining rules you are following.

For a full artifact, use this file's task worksheets and source limits. Other downloads and BuyerTwin are optional. The supporting tabs provide usage help, not missing essential rules.

Sources and evidence limits

• Google Search Central: Site moves with URL changes supports relevant mappings, permanent redirects, retirement responses, links, and crawl/monitoring checks. It does not guarantee unchanged rankings.
• W3C Forms Tutorial supports labels, instructions, validation, and success/error feedback. Actual submission receipt requires its own operational test.
• W3C Easy Checks provides preliminary accessibility checks and explains their limits; a quick pass is not comprehensive evaluation.
• NNGroup: Mental Models explains how users' knowledge and expectations can differ from a designer's detailed understanding.

The requirement-ranking exercise, phased record, and release decisions are Insivia's practitioner synthesis. Sources support specific practices, not the effectiveness of a hypothetical project. No client outcome, human study, BuyerTwin analysis, completed migration, or ranking effect is established here. Retain Insivia attribution and evidence distinctions when adapting the file.

Optional handoffs

Each linked playbook answers a different next question. This file already contains its own essential method and working resources; no other download is required.

• Plan a buyer-centric website when buyer strategy or page responsibilities are still unresolved.
• Choose visuals buyers can interpret when delivery needs a simpler visual explanation that preserves the verified offer.
• Improve calls to action and forms when CTA, form or follow-up behavior needs to be defined and checked.
• Test and improve buyer alignment when you are ready for neutral buyer-task checks and post-launch diagnosis.