How to Protect SEO, AI Search Visibility, and Lead Measurement During a Website Redesign
Tomohiro Iida · Published August 13, 2026 · Updated August 13, 2026
A website redesign is not only a change to visual design or a CMS. When URLs, copy, initial HTML, structured data, internal links, calls to action, forms, and measurement settings change together, the connection between discovery and enquiries can break. This article is a practical checklist for protecting that sales foundation before and after a redesign.
This article covers what to preserve before the redesign, what to check on launch day, and what to review after launch. It does not cover design quality, CMS selection, or how to compare production companies. Its scope is the continuity of URLs, search and AI visibility, enquiry paths, and measurement.
The current Netsujo SIGNAL process uses five stages: Observe the symptom, Trace the implementation cause, Specify the change, Execute the implementation, and Verify the published state and results. The Netsujo SIGNAL service page publishes the inputs, outputs, and analysis scope for each stage.
Conclusion: create a keep, change, or retire map before the redesign
The first document should be a URL and sales-foundation map, not a design proposal. Decide which old URLs map to which new URLs, what information will be carried forward, and what will be retired. Then separate three moments of verification.
- Before launch: preserve important URLs, search and enquiry baselines, business facts, and measurement events.
- Immediately after launch: check redirects, canonicals, initial HTML, structured data, internal links, calls to action, and forms.
- After launch: use roughly seven days for early anomalies and roughly twenty-eight days for comparing search, access, and enquiry changes with a baseline.
Seven and twenty-eight days are our operating guidelines, not universal rules. Site size, update frequency, and seasonality can require different windows, so decide the comparison period and reviewer before launch. Search rankings, inclusion in AI answers, and enquiry volume cannot be guaranteed.
1. Preserve six baselines before the old site changes
If you wait until the new site is complete, you may no longer be able to reproduce the old state. Save at least the following items with the collection date and source.
| What to save | Minimum contents | Where it is used |
|---|---|---|
| Important URLs | Service, pricing, case, enquiry, and high-traffic article URLs | URL mapping and launch-day link checks |
| URLs and queries | Search Console impressions, clicks, CTR, position, and queries | Comparing search performance after launch |
| Enquiry paths | CTA, form-start, form-completion, phone, and email event names and parameters | Migrating measurement events |
| Business facts | Company, service, target customer, scope, pricing, proof, and contact information | Checking copy, metadata, and JSON-LD consistency |
| AI-search observations | Question, service, region, execution date, and the answer or citation observed | Repeating an observation under the same conditions |
| Implementation owners | CMS, repository, tag, domain, Search Console, and GA4 owners | Launch work and incident response |
Save Search Console and GA4 numbers with a fixed period. If a value is not available, record “not measured” rather than zero. AI answers are not fixed results, so retain the question, date, service, region, and provider used rather than only the company name.
2. Check URL mapping, redirects, and canonical URLs together
For a redesign that changes URLs, the first inspection target is the mapping between old and new URLs. Google Search Central’s site-move guide treats the URL map, redirects, and post-launch monitoring as one sequence.
| Old URL state | Decision for the new site | What to verify |
|---|---|---|
| Content is carried forward | Choose one new URL | The old URL redirects to a relevant new URL |
| Several pages are consolidated | Define the destination content | The redirect does not send users to an unrelated home page |
| Publication ends | Decide whether a replacement exists | Use the appropriate 404 or 410 when there is no replacement |
| URL stays the same | Keep the URL and record the changed scope | Check copy, metadata, and measurement changes |
A redirect alone does not complete the migration. Check that the new canonical, robots noindex rules, sitemap entries, internal links, and language links follow the same policy. Google lists redirects, rel="canonical", and sitemap inclusion as canonicalisation signals with different strengths and roles; use the official canonical guide when deciding how they should work together.
- Old URL
- New URL
- Redirect type and implementation location
- Canonical URL on the new page
- Sitemap inclusion
- Internal-link sources to update
- Owner
- Post-launch check date
3. Check initial HTML, metadata, and structured data separately
A page that looks correct in a browser does not necessarily expose the same information in initial HTML, the DOM after JavaScript runs, and structured data. Check where the important service name, target customer, outcome, and contact path are rendered.
| Surface | What to inspect | Common omission |
|---|---|---|
| Initial HTML | H1, core explanation, price, canonical, and robots | Important copy exists only after JavaScript runs |
| Metadata | Title, description, canonical, and Open Graph | An old title or canonical remains in a template |
| Structured data | JSON-LD type and key properties | A price, FAQ, or proof remains only in JSON-LD |
| Rendered DOM | Visible copy, links, and forms | The hydrated page differs from the initial HTML |
| Internal links | Navigation, related articles, and CTAs | The new service page becomes orphaned |
Structured data provides explicit clues about the meaning of a page, but correct implementation does not guarantee a search appearance. Match the visible content to the markup and validate the page after launch with Google’s structured-data guidance and the Rich Results Test.
How to check JavaScript rendering and crawlers
Structured data implementation guide
4. Migrate CTA and form measurement as user actions, not button names
When a redesign changes the button or form implementation, GA4 events may stop firing, or the same click may be counted twice. Before launch, list the old events and decide how each one will work on the new site.
| Action | What to preserve | Post-launch check |
|---|---|---|
| CTA click | Event name, label, location, and destination | Click each CTA and confirm one event fires |
| Form start | Event name, form identifier, and landing page | Confirm the correct form is recorded at input start |
| Form completion | Event name, completion condition, and thank-you URL | Confirm it fires only on completion and not on reload |
| Phone or email | Event name, link type, and page | Test on both mobile and desktop |
| Consultation or download | Event name, service, and source | Compare the action by service and landing page |
GA4 events measure user interactions and can be checked in Realtime and DebugView. Use the official GA4 event guide to document event names and parameters, and keep the page, service, and source context needed to understand the path to an enquiry.
How to connect SEO and AI search work to lead measurement
5. Turn each redesign issue into an implementation specification
“Do not lose SEO,” “support AI search,” and “carry over measurement” are directions, not implementation tasks. For each issue, write the target URL, confirmed fact, change, completion criteria, and post-launch check in one specification.
| Field | Example during a redesign |
|---|---|
| Target URL | Old /service/a and new /services/a |
| Confirmed fact | The old URL received impressions in the last twenty-eight days and has no mapped destination |
| Implementation cause | No owner has been assigned to the URL map, redirect, or canonical |
| Change | Redirect the old URL, and register the new URL as canonical and in the sitemap |
| Completion criteria | Production redirect, canonical, sitemap, and internal links match the map |
| Release-day verification | Fetch both URLs and check status, final URL, canonical, and noindex |
| Twenty-eight-day review | Compare impressions, clicks, CTR, and CTA or form completion with the baseline |
How to write a web improvement specification
6. Separate launch-day, seven-day, and twenty-eight-day checks
Search rankings cannot tell you on launch day whether the implementation is correct. Conversely, if status codes or forms are not checked immediately, a defect can remain throughout the observation period.
| Timing | Main checks | Decision |
|---|---|---|
| Immediately after launch | Important URLs, redirects, canonicals, robots, sitemap, initial HTML, metadata, JSON-LD, CTAs, forms, and visual regressions | Is the technical release complete? |
| Around seven days | Search Console old and new URLs, sitemap, indexing status, redirect errors, and GA4 events | Are there early migration or measurement omissions? |
| Around twenty-eight days | Impressions, clicks, CTR, organic sessions, CTA, form completion, and enquiry quality | What should be improved next against the baseline? |
A metric can move after a redesign without the redesign being the only cause. Record seasonality, new content, advertising, competitors, and search-system changes, and keep observed facts separate from inferences.
7. Hand over a verifiable change without replacing the existing production partner
The implementation owner and the person organising search, AI, and measurement issues do not have to be the same company. Give the existing production partner a package they can estimate and implement.
- The URL map and the keep, change, or retire decision
- The baseline values and their sources
- The implementation differences between old and new
- Owners for the CMS, repository, tags, domain, GA4, and Search Console
- A specification for each issue with completion and release-day checks
- Open questions, unresolved items, and decision deadlines
Netsujo SIGNAL does not assume that the existing production company must be replaced. The free diagnosis uses public information; depending on permissions and scope, paid support can include GA4, Search Console, CMS, repository, and GTM review. Where appropriate, findings can be converted into implementation specifications, code examples, diffs, or pull requests.
AIO and AI search support from diagnosis to implementation
Frequently asked questions
- If the URLs do not change, do we still need an SEO check?
- Yes. The URL-migration checks become smaller, but initial HTML, titles, canonicals, structured data, internal links, CTAs, forms, and measurement tags can still change.
- Does setting up redirects complete the migration?
- No. Check the destination content, canonical, sitemap, robots, internal links, language links, measurement, and post-launch Search Console data. Map each old URL before deciding the redirect.
- Can the existing production company implement the changes while SIGNAL handles diagnosis?
- Yes. The important step is to convert findings into target URLs, confirmed facts, exact changes, completion criteria, and verification steps, then agree on owners, permissions, and the release date.
Key takeaways
- Preserve URL, search, enquiry, business, and measurement baselines.
- Map old and new URLs before deciding redirects.
- Check initial HTML, metadata, JSON-LD, DOM, CTAs, and forms separately.
- Write implementation specifications instead of general redesign directions.
- Separate launch-day verification from seven-day and twenty-eight-day evaluation.
Public information only. The free diagnosis helps identify the first URL and fact to check before a redesign.
Start the Netsujo SIGNAL free diagnosisSee the Netsujo SIGNAL service