More insights.
Subscribe to our newsletter.
Deep dives into design thinking, creative process, and the intersection of business and aesthetics.
Protect the useful journeys before you replace the website.
A website redesign should start with a record of what the current site does for the business. Identify the pages people find, the questions those pages answer and the enquiries they support. Then decide what to keep, improve or replace. This checklist helps an Irish organisation put those decisions into a brief, test the replacement and assign responsibility for launch.
If you are still deciding whether to replace the site, our rebuild planning article can help frame that decision.
1. Save a baseline with dates and filters
Export Search Console clicks, impressions, queries and landing pages before the work begins. Keep the source dates, country, device and search-type filters with the export. Review organic enquiries alongside search visibility, with test submissions and duplicate events identified. If the measurement is incomplete, record that limitation before using it to judge a redesign.
Use comparable periods. A partial month and a complete month cover different amounts of time, and a change in Direct sessions does not establish a change in Google rankings. Keep brand searches separate from discovery queries where the data allows. Choose the measures that relate to the brief, such as useful enquiries, content discovery or a completed booking journey.
2. Inventory valuable URLs and the content behind them
Combine a crawl and the current sitemap with search, enquiry and link evidence. Include useful PDFs, campaign pages and routes that are absent from the main menu. Record each important URL, its purpose, the content that must survive and the person who owns it. A page with little traffic can still be important to someone making a substantial buying decision.
Give each page a decision: retain its URL, improve its content, combine it with a relevant destination or retire it for a stated reason. Keep existing addresses when there is no useful reason to change them. A visual redesign does not require a new URL structure.
3. Agree the redirect map before launch
For a changed address, map the old URL to the most relevant new destination and assign someone to implement and test the server-side permanent redirect. Update internal links to use the final addresses. Google’s site-move guidance explains the mapping and redirect process.
A fictional example: /old-services could move to /services when the replacement answers the same service question. An old installation guide could move to its replacement guide. Sending every retired page to the homepage can leave visitors without the information they expected. Record the reason and test the destination for each important route.
4. Review page identity and search access
Check titles, descriptions, headings, important internal links and relevant structured data against the actual content. Confirm the intended canonical address and use it consistently in links and the sitemap. Google’s canonical guidance describes these signals; a canonical is not a substitute for a redirect when a page has moved.
Keep the test environment’s access controls separate from the live configuration. Before launch, confirm that intended public pages are accessible to crawlers and do not carry an unintended noindex rule. A robots.txt block can prevent Google from seeing a noindex instruction, as its indexing-control guidance explains. Put these checks in the launch record rather than relying on an editor setting alone.
5. Test the journeys a buyer actually needs
Ask a representative user to find a service, inspect relevant work and reach the enquiry route. Test realistic content on a narrow phone screen, with a keyboard and at a larger text size. Check that the opening explanation is readable promptly and that important links and information remain accessible while scripts load.
Check forms, validation, booking tools, downloads and required integrations. For an agreed test submission, reconcile the success screen, receiving system and analytics event. Record what was delivered and exclude the artificial enquiry from business reporting. A confirmation screen alone cannot establish that the enquiry reached the team.
6. Carry measurement and consent through the change
List the analytics properties, tag configuration, events, consent controls and external tools the replacement uses. Name the account owners and the person testing them. Check accepted and rejected choices, duplicate events and any cross-domain booking route. Preserve comparable definitions so a tracking change is not mistaken for a change in demand.
7. Name the launch and rollback owners
Agree who can publish, who checks the public result, who receives enquiry-test messages and who can restore a working version. Save the current content, configuration and release evidence before switching. Define a response for a broken enquiry route, inaccessible page or incorrect indexability setting, and preserve newer legitimate edits when applying a selective rollback.
After publication, fetch the actual public pages and follow the old URLs. Confirm the intended responses, page content, canonical addresses and live enquiry access. Check both initial HTML and the rendered experience where the platform uses JavaScript. An editor preview and a successful deployment message are useful steps, but public verification closes the release.
8. Compare like periods after the release
Annotate the release date and any later material changes. Compare complete periods using the same source filters and metric definitions, allowing for reporting lag. Watch valuable landing pages and query groups alongside enquiries. Investigate a changed result against seasonality, campaigns, competitors and measurement changes before attributing it to the redesign.
Keep a short intervention log: what changed, why, when it went live and what evidence would justify the next decision. Correct a verified broken page or form promptly. Give a small or noisy search sample enough time to become useful before rewriting the same page again.
Use the checklist to compare delivery proposals
Ask each supplier for a URL inventory, redirect responsibility, content ownership list, test plan, public launch checks and a monitoring arrangement. Each item should have an owner and a reviewable output. The useful question is what the team will demonstrate before accepting the launch.
Brainstorm’s website design service brings strategy, content, UX and development together. The Ireland service explains online delivery for organisations across the country. For a venue with several visitor needs, the Thomond Park case study shows how distinct information and enquiry journeys can sit within one website.
Prepared 16 October 2026. Dave Curtin, founder and Creative Director of Brainstorm, leads website strategy, brand direction and technical delivery for Brainstorm clients.
Protect the useful journeys before you replace the website.
A website redesign should start with a record of what the current site does for the business. Identify the pages people find, the questions those pages answer and the enquiries they support. Then decide what to keep, improve or replace. This checklist helps an Irish organisation put those decisions into a brief, test the replacement and assign responsibility for launch.
If you are still deciding whether to replace the site, our rebuild planning article can help frame that decision.
1. Save a baseline with dates and filters
Export Search Console clicks, impressions, queries and landing pages before the work begins. Keep the source dates, country, device and search-type filters with the export. Review organic enquiries alongside search visibility, with test submissions and duplicate events identified. If the measurement is incomplete, record that limitation before using it to judge a redesign.
Use comparable periods. A partial month and a complete month cover different amounts of time, and a change in Direct sessions does not establish a change in Google rankings. Keep brand searches separate from discovery queries where the data allows. Choose the measures that relate to the brief, such as useful enquiries, content discovery or a completed booking journey.
2. Inventory valuable URLs and the content behind them
Combine a crawl and the current sitemap with search, enquiry and link evidence. Include useful PDFs, campaign pages and routes that are absent from the main menu. Record each important URL, its purpose, the content that must survive and the person who owns it. A page with little traffic can still be important to someone making a substantial buying decision.
Give each page a decision: retain its URL, improve its content, combine it with a relevant destination or retire it for a stated reason. Keep existing addresses when there is no useful reason to change them. A visual redesign does not require a new URL structure.
3. Agree the redirect map before launch
For a changed address, map the old URL to the most relevant new destination and assign someone to implement and test the server-side permanent redirect. Update internal links to use the final addresses. Google’s site-move guidance explains the mapping and redirect process.
A fictional example: /old-services could move to /services when the replacement answers the same service question. An old installation guide could move to its replacement guide. Sending every retired page to the homepage can leave visitors without the information they expected. Record the reason and test the destination for each important route.
4. Review page identity and search access
Check titles, descriptions, headings, important internal links and relevant structured data against the actual content. Confirm the intended canonical address and use it consistently in links and the sitemap. Google’s canonical guidance describes these signals; a canonical is not a substitute for a redirect when a page has moved.
Keep the test environment’s access controls separate from the live configuration. Before launch, confirm that intended public pages are accessible to crawlers and do not carry an unintended noindex rule. A robots.txt block can prevent Google from seeing a noindex instruction, as its indexing-control guidance explains. Put these checks in the launch record rather than relying on an editor setting alone.
5. Test the journeys a buyer actually needs
Ask a representative user to find a service, inspect relevant work and reach the enquiry route. Test realistic content on a narrow phone screen, with a keyboard and at a larger text size. Check that the opening explanation is readable promptly and that important links and information remain accessible while scripts load.
Check forms, validation, booking tools, downloads and required integrations. For an agreed test submission, reconcile the success screen, receiving system and analytics event. Record what was delivered and exclude the artificial enquiry from business reporting. A confirmation screen alone cannot establish that the enquiry reached the team.
6. Carry measurement and consent through the change
List the analytics properties, tag configuration, events, consent controls and external tools the replacement uses. Name the account owners and the person testing them. Check accepted and rejected choices, duplicate events and any cross-domain booking route. Preserve comparable definitions so a tracking change is not mistaken for a change in demand.
7. Name the launch and rollback owners
Agree who can publish, who checks the public result, who receives enquiry-test messages and who can restore a working version. Save the current content, configuration and release evidence before switching. Define a response for a broken enquiry route, inaccessible page or incorrect indexability setting, and preserve newer legitimate edits when applying a selective rollback.
After publication, fetch the actual public pages and follow the old URLs. Confirm the intended responses, page content, canonical addresses and live enquiry access. Check both initial HTML and the rendered experience where the platform uses JavaScript. An editor preview and a successful deployment message are useful steps, but public verification closes the release.
8. Compare like periods after the release
Annotate the release date and any later material changes. Compare complete periods using the same source filters and metric definitions, allowing for reporting lag. Watch valuable landing pages and query groups alongside enquiries. Investigate a changed result against seasonality, campaigns, competitors and measurement changes before attributing it to the redesign.
Keep a short intervention log: what changed, why, when it went live and what evidence would justify the next decision. Correct a verified broken page or form promptly. Give a small or noisy search sample enough time to become useful before rewriting the same page again.
Use the checklist to compare delivery proposals
Ask each supplier for a URL inventory, redirect responsibility, content ownership list, test plan, public launch checks and a monitoring arrangement. Each item should have an owner and a reviewable output. The useful question is what the team will demonstrate before accepting the launch.
Brainstorm’s website design service brings strategy, content, UX and development together. The Ireland service explains online delivery for organisations across the country. For a venue with several visitor needs, the Thomond Park case study shows how distinct information and enquiry journeys can sit within one website.
Prepared 16 October 2026. Dave Curtin, founder and Creative Director of Brainstorm, leads website strategy, brand direction and technical delivery for Brainstorm clients.