A better-looking website still needs a migration plan. Keep useful pages, map changed addresses and check the live launch without promising unchanged rankings.
The new website is almost ready. The pages look better, the copy is clearer and the navigation is shorter. Then someone asks what happens to all the old addresses that people already find and share.
That question belongs near the start of a redesign. A new visual design doesn't require throwing away useful pages, and changed addresses need a plan before launch.
Can you guarantee that a redesign won't affect rankings?
You can reduce avoidable mistakes, but you cannot promise unchanged search results.
A redesign can preserve useful content and keep existing links working through deliberate URL planning, testing and monitoring. Google still needs to process significant changes, and rankings or traffic can fluctuate.
Google's site-move guidance recommends planning changes carefully and monitoring the old and new versions. It also distinguishes a layout change from a move involving new URLs.
Start by naming what is actually changing: the appearance, content, page addresses, domain, CMS or several of those together. They create different jobs and risks.
If the current website has never appeared in Google, begin with the indexing checks. A redesign migration and an existing access problem should not be confused.
Which existing pages are worth keeping?
Build an inventory before replacing the navigation.
Collect the current page addresses from the website and sitemap. Use available Search Console and analytics data to identify useful search entrances, enquiries and content people still use. Include important pages even when their recent traffic is low.
Record what each page does for the visitor. A service page, work example and practical guide may support different stages of a decision.
Then mark each page: keep, revise, combine, move or remove. Keep the original address when it still suits the content and there is no useful reason to change it.
For a hypothetical consultancy, a detailed survey page might deserve a better layout rather than deletion. A redundant campaign page may need a different decision. Review the material instead of assuming everything old is disposable.
How do you map changed page addresses?
Every old address needs an intentional destination or removal decision.
Create a simple mapping document for the developer.
| Old page | Planned treatment | What to verify |
|---|---|---|
| A useful service page at the same address | Redesign in place | Relevant content and page information remain |
| A service page moving to a new address | Redirect to the corresponding new service | The destination answers the same need |
| Two overlapping guides becoming one | Review and combine useful material | The replacement genuinely covers both |
| An obsolete offer with no suitable replacement | Deliberate removal | Visitors receive a useful explanation or proper missing-page response |
Don't send every retired page to the homepage just to avoid seeing an error. A redirect should lead to a relevant replacement. Google explains permanent redirects and the difference between redirect methods.
Ask the developer to check the actual response, not only whether clicking a link eventually reaches a page. Keep the mapping with the project records.
For example, suppose /services/office-surveys becomes /services/workplace-surveys. Ask for a permanent server redirect from the old address directly to the new one. The new page should load successfully and explain the same service. A chain through an unrelated page is a reason to revisit the mapping.
What should be checked before launch?
Review the new website as both a visitor and a collection of public pages.
Confirm that important content survived the rewrite and that internal links point to the intended addresses. Check page titles, main headings, canonical URLs and the sitemap where relevant.
Have the developer distinguish preview restrictions from the settings that should go live. A preview may correctly be kept out of search; carrying those restrictions into production can create a different problem.
Ask for a launch checklist with named owners. It should cover removing production noindex restrictions, checking the preferred page address (the canonical URL), testing redirects and updating the sitemap. Google covers these checks in its site-move guidance above. Leave the preview protected while making sure the public website can be crawled.
Test the main enquiry route as well. Preserved traffic has little value if the redesign breaks contact. Our website campaign checks cover the visit through to a confirmed result.
Use the old-to-new mapping as a test list. Open representative old addresses directly rather than relying only on the new menu.
If you're replacing a dated marketing website, we can scope the new design alongside the content and address changes it needs. That gives the rebuild a deliberate page structure instead of treating migration as a last-minute task. We agree the work before building; search performance itself cannot be guaranteed. Book a free intro call, or send the current site to hi@aruno.studio, WhatsApp or Telegram @mihaipostelnicu.
What should you watch after the redesign goes live?
Check the production website rather than assuming the preview proves the launch.
Open important new and old addresses on the real domain. Confirm redirects, links and the contact route. The guide to preview-versus-live failures helps if a feature behaved differently during review.
Monitor Search Console for access or indexing issues and compare the performance of important pages over a sensible period. Note the launch date, content changes and other events that could affect comparisons.
Some search changes take time to process. Don't respond to a brief fluctuation by changing every title, URL and section again. Investigate a specific failure when there is evidence of one.
If an old address returns a missing-page error, check it against the mapping. If the page loads but is absent from search, inspect that exact URL in Google Search Console. Look at indexing information and Google's chosen canonical address before deciding which setting needs attention.
Keep the old inventory, redirect map and launch checks in the handover material. The next person needs to understand which decisions were intentional.
Frequently asked questions
Should I change the domain during the redesign? Only when the business needs it. A domain change adds migration work. Discuss whether changes can be separated so their effects are easier to understand.
Do new page designs need new URLs? No. The layout can change while an appropriate existing address stays the same. Avoid changing URLs merely because the visual design is new.
Should I keep all the old copy? Keep useful information and review it carefully. You can make the writing clearer without removing answers visitors rely on. A rewrite needs a content decision, not an automatic word-for-word copy.
How quickly will Google reflect the redesign? There is no fixed timetable for every site or page. Google needs to crawl and process changes, so monitor the actual URLs and use the available Search Console tools rather than promising a date.
Does preserving SEO cost extra during a redesign? Ask the quote to name the page inventory, content review, redirect mapping, testing and post-launch monitoring. The work depends on what changes and how many pages need attention; don't assume it is included in a visual-design quote.
Put the old page list beside the new design before launch. Every important address should have a deliberate next home.
