How to think about a marketing site rebuild

Make a repair-versus-rebuild decision with explicit assumptions

Assume a service business has a vague web-development page and an enquiry form whose receiving-system behavior has not been verified. For this exercise, the existing CMS already lets the intended editor revise service fields and publish a long case study. There is no stipulated requirement that the current content model cannot represent. These are invented constraints, not findings about a live CMS.

Option A is to repair the service page and investigate the complete enquiry path while keeping the current templates and useful URLs. It directly addresses the missing buyer information and the unverified delivery boundary. It does not deliver a new design system, and it will not fix an unrelated limitation discovered later in the publishing workflow.

Option B is to rebuild the templates or change the CMS. It may be appropriate if the current structure prevents required changes, but that has not been established in this scenario. It introduces content transfer, editor training and release work alongside the original problems. A more attractive homepage alone is not evidence that those additional tasks solve them.

My recommendation under these assumptions is Option A first, because replacing a working publishing capability is not required to clarify the offer or verify form delivery. Revisit the decision if the actual editor cannot complete a required workflow, a necessary page type cannot be maintained, or an operational constraint cannot be repaired within the agreed scope. The recommendation is conditional, not a claim that repairs are always cheaper.

For a real decision, have the intended editor perform the required task with representative content. Include a missing image, a correction to published wording and whatever approval step the business needs. Observe where work stops and record the requirement that failed. Do not turn this proposed exercise into a statement that a particular CMS has passed.

Ask for route outcomes rather than a list of redirects

The executable routing witness uses Python 3.12.12 and a real HTTP server on container loopback. It checks the response before following a redirect, then requests the destination and verifies its body. All paths and page bodies are synthetic; the module is not a configuration for your host or an implementation of Ulties production routing.

The observed moved-page case is GET /services/web-development?ref=demo returning 301 with Location /services/product-engineering?ref=demo. Requesting that destination returns 200 and the expected service body. The trailing-slash variant also goes directly to the final destination. Encoded values, repeated query keys and an empty query are checked separately. This fixture deliberately preserves its harmless query values; a real site needs its own parameter and privacy policy.

The retained /blog/csv-imports path returns 200 with its existing article body and no Location header. The retired /events/retired-workshop path returns 410 with no redirect. An unknown path returns 404 instead of going to the homepage. These are distinct outcomes: interpreting every row of a migration inventory as a redirect would break the retained and removed cases.

Twenty-one assertions pass normally. Five actual altered implementations drop the query, send unknown paths to the homepage, redirect gone content, introduce a trailing-slash chain or turn the retained page into a self redirect. Each must fail its intended assertion after the expected preceding checks. A syntax error or unrelated crash does not count as a detected routing defect.

Download the source and run python3 frontend/content-quality/fixtures/rebuild-routing/verify.py results.json from its root with Docker available. The pinned runner has no external network or credentials and exposes no host port. The server is container-local. No CDN, proxy, TLS, crawler, canonical tag or live migration was tested. Use these observations as a contract for the real routing implementation to prove.

Keep indexing, preview privacy and enquiry receipt separate

Google’s site-move guidance supports relevant URL mapping, direct permanent server redirects and updated internal links and canonical references. It also distinguishes removed content, which may need a 404 or 410 response. The HTTP witness illustrates those outcomes; it cannot demonstrate that Google has crawled or indexed anything, and a successful status code is not evidence of preserved search traffic.

A private preview needs access control. A noindex rule concerns search indexing and is not a login requirement. Google documents that crawlers must be able to retrieve the rule to follow it, so blocking crawling can prevent that discovery. At launch, verify the public site’s intended indexing controls separately from the private preview’s access restrictions. No such access-control or crawler test is implemented in the routing witness.

For enquiries, distinguish a browser acknowledgement from acceptance by your application and receipt by the receiving system. A button click or confirmation screen does not show that a message arrived. In an authorized test environment, use clearly marked synthetic submissions to inspect validation errors, repeat submissions, application failures and downstream delivery failures. Define what is persisted and how the user can recover; these are proposed acceptance checks, not passed tests in this article.

Include keyboard operation and understandable errors in the actual interface review. W3C’s Easy Checks is a preliminary review and explicitly does not establish complete accessibility conformance. Agree the target and fuller assessment required for the project rather than presenting a quick scan as certification.

Accept the result against the problem you funded

For the fictional repair, the content owner should approve whether the service page answers the buyer’s suitability questions. Engineering should demonstrate the chosen enquiry and routing boundaries. If a later rebuild is justified, also require the intended editor to maintain the representative page types before accepting the implementation. The business needs a working publishing workflow, not just a homepage approval.

Before launch, record a baseline for whatever outcome you intend to change and how it is collected. A tracking change can make a before-and-after comparison difficult to interpret. This article supplies no traffic baseline, conversion target or causal sales claim.

I recommend keeping a rollback plan for application code and routing, with separate handling for content or data changes a redeploy cannot undo. Name who reviews failures after launch and what evidence would trigger rollback. The practical decision is whether the funded problem has been addressed and the remaining risks have owners. A broad rebuild is one possible means to that result, not the acceptance criterion itself.