How to think about a marketing site rebuild
Scope a rebuild around buyer journeys, publishing needs, URL migration, and launch checks that protect working behavior.
Find a failure that a rebuild can address
A marketing site can look dated and still help buyers make a decision. It can also look polished while hiding product limitations, breaking contact forms, or making routine edits dependent on a developer. Diagnose those problems before choosing a replacement stack.
Take a representative journey: a buyer arrives on a service page, looks for evidence, checks suitability, and requests a conversation. Identify the missing information or broken interaction at each step. Use real evidence where available, but label assumptions and illustrative examples rather than inventing conversion losses.
Compare a focused repair with a rebuild. If the main issue is an unclear offer, rewriting a service page may be enough. A rebuild becomes easier to justify when the existing content model, deployment process, or interface structure prevents repeated improvements.
Prototype the hardest page and the publishing workflow
Do not approve a design system from the homepage alone. Try a long service page, a technical article with code, a case study with imperfect assets, and a form with validation errors. These expose constraints that an idealized hero section will hide.
Have an editor create and revise representative content before the implementation is considered settled. Test previews, required fields, missing images, and the ability to correct a published mistake. An interface that needs a developer for every correction has not met an editorial independence goal.
Write down which parts of a page are structured and which are free text. A comparison table needs different editing rules from a paragraph. Avoid a generic page builder if a few explicit page types cover the actual publishing needs.
Treat old URLs as inputs to the project
Inventory current public paths and decide which survive, move, or disappear. This JSON is an illustrative migration manifest for review; it does not configure any particular host. An implementation must translate it into the routing system and test the resulting responses.
[
{
"from": "/services/web-development",
"to": "/services/product-engineering",
"status": 301,
"reason": "Equivalent service page with revised wording"
},
{
"from": "/blog/csv-imports",
"to": "/blog/csv-imports",
"status": 200,
"reason": "Preserve an existing useful URL"
},
{
"from": "/events/retired-workshop",
"to": null,
"status": 410,
"reason": "Removed event with no relevant replacement"
}
]Make launch acceptance observable
Google's migration guidance supports direct permanent redirects to relevant replacements. Check the mapping with actual HTTP responses, including trailing-slash variants and any old redirects that might form chains. Inspect canonical URLs, internal links, and the sitemap for references to the intended public routes.
Protect preview environments with access control where content is private. Before launch, verify the public site's intended indexing settings explicitly; a forgotten noindex rule can survive an otherwise successful release. Separately confirm that genuinely private previews remain private.
Test the contact journey from the browser through the receiving system with clearly marked test submissions. Verify required-field errors, duplicate clicks, backend failure, and confirmation behavior. Do not count a button click as a successfully delivered enquiry.
Use keyboard and zoom checks alongside automated accessibility tools. W3C's preliminary review covers useful first checks but is not a complete audit. Define the project's accessibility target and who will assess it.
Decide what happens after launch
Record a pre-launch baseline for the measures the project intends to change: qualified enquiries, successful form delivery, publishing time, or search traffic to key pages. Note how each measure is collected. A changed analytics setup can otherwise look like changed customer behavior.
Keep a rollback procedure for the application and routing configuration, including any CMS changes that cannot be reversed by redeploying code. Assign an owner to review broken routes and form failures after launch, and make the first review part of the delivery scope.
A rebuild is complete when the important journeys work, editors can maintain the content, and the team can detect and correct failures. Visual approval is one input to that decision.