A rebuild of the site based on the content, catalog, and paths the company needs to support today, while protecting what already works.
To add a new product, someone has to call the developer.
When does this solution make sense?
| When it makes sense | It's for | It's not for |
|---|---|---|
| A company that depends on a vendor for every change, or that has to migrate platforms. | ||
| A company with a new marketing lead who needs to know what's there before deciding. | ||
| A company that doesn't want to lose the traffic Google currently sends to its product pages and documents. | ||
| A visual refresh on the same structure to be ready for a congress in a few weeks. Other providers are better suited for that. |
How this solution comes together
Design comes in once it's clear what the page needs to support.
What already exists comes first, followed by the structure and copy, and only then the screens.
Old URLs lead to their new destinations, preserving traffic to content that already had it.
The structure can accommodate new products, markets, or languages without being rebuilt.
- Product pages, two and a half times as many1,308 → 3,227 clicks
- Catalog PDFs:1,391 → 324 clicks
- audited to their final destination, none broken511 redirects
FAQ
How can traffic be preserved when moving to a new site?
With a redirect map that sends each old URL to its new destination and is audited after launch.
What happens to PDFs that still get visits from Google?
They're redirected to the product page that replaces them, or kept and linked from it if someone still uses them. It's decided document by document.
The site is slow: does it need to be rebuilt?
Not always. Sometimes web performance work is enough; the audit shows which situation applies.
How can the company tell whether the redesign worked?
By comparing equal time windows before and after: product page visits, documentation downloads, and site searches. The measurement is repeated a few months later.