A website redesign can improve a Dubai business's presentation while accidentally removing pages that already bring useful visitors. Before approving the new design, agree which existing URLs, content and enquiry routes must survive. Search visibility cannot be guaranteed during a change, but a documented migration makes avoidable losses easier to prevent and diagnose.
When briefing website design and development, include migration and post-launch checks as deliverables. They should have an owner and an acceptance condition, just like the visual design.
Build a register before changing URLs
| Register field | What the business and agency should decide |
|---|---|
| Existing URL | What page or downloadable asset currently exists? |
| Commercial role | Which service or buyer question does it support? |
| Available evidence | Does it receive relevant search traffic, links or enquiries? |
| Intended action | Retain, improve, consolidate or remove with a reason |
| New destination | Where will the same useful information live? |
| Implementation owner | Who changes the page and any required routing? |
| Acceptance evidence | How will the team demonstrate that the intended journey works? |
Do not use traffic alone to decide whether a page matters. A low-volume service page may answer a valuable buying question. A high-traffic article may attract readers who never need the service. Review the page's purpose and available commercial evidence before deleting or merging it.
Preserve useful destinations
Google's site-move guidance recommends mapping old URLs to appropriate new destinations and using permanent server-side redirects where possible. It warns against redirecting many unrelated pages to the homepage. Use that guidance to review the technical plan with the developer; a new homepage is not automatically the replacement for every old service page.
Keep valuable content accessible in the redesigned page. A new visual layout should not silently remove the explanation that made the page useful. Include important images and downloads in the migration discussion, especially when sales teams or external websites already link to them. Record intentional removals so they are not confused with launch defects.
Check the buyer journey on the release candidate
Have someone outside the build team find a priority service, inspect its evidence and submit a test enquiry. Check the mobile version and every supported language. Confirm that the receiving team gets the correct service context. A page can look finished while its form, booking link or translated destination still fails.
Agree a release record containing the launch time, URL changes and material content changes. Google's migration documentation also calls for checks of canonical and indexing directives and the new sitemap. Ask the developer to provide the relevant technical evidence rather than treating a green design approval as proof that search access is correct.
Decide what is changing before calling the work a redesign
A visual refresh, a new content structure and a move to another domain create different work. List the actual changes in the brief: layouts, page text, addresses, language structure, forms, booking links and any supporting systems. The agency should explain which parts it controls and which require another supplier. A proposal that only describes the new appearance leaves the business unable to assess the release risk or the implementation effort.
Separate the reason for each change from the change itself. A service page may need clearer content without needing a different address. A confusing navigation label can be corrected without removing the underlying page. A genuine service consolidation may justify a broader restructure. Ask the team to show the intended improvement and the existing journeys affected, instead of assuming every redesign needs every part of the site replaced.
Build the inventory from business use as well as analytics
Ask sales and operations which links they send to customers. Include the pages used in proposals, email signatures, messages and active campaigns. Identify useful downloads and project examples. These may matter even when they receive little general traffic. The migration register should represent how the website is used, not just the most popular rows in a dashboard.
For each priority destination, record the buyer question it answers and the action it supports. If the new design combines several pages, identify where each useful explanation will appear. The review should be specific enough that a subject expert can spot missing information before launch. “Moved into the new services section” is not a complete answer when nobody can show the relevant content there.
Keep intentional removals separate from unresolved decisions. The business may choose to stop advertising a service or withdraw an outdated document. Record that decision and the treatment of people who still arrive through an old link. A page should not disappear simply because it was omitted from a design file or assigned to nobody during content production.
Review a sample migration map before approving the whole list
Use a small set of representative journeys to check the proposed approach. Include a main service, a useful article, a project example, a download and a language version where relevant. Ask the developer to demonstrate the intended destination and the content available there. This exposes misunderstandings while the team can still correct the approach before applying it across the site.
| Existing journey | Review question for the proposed release |
|---|---|
| Customer opens a saved service link | Can they still reach the relevant service explanation? |
| Sales sends a project example | Does the project remain accessible with accurate attribution? |
| An advert points to an offer | Does the destination still match the active message? |
| A visitor changes language | Do they reach the equivalent page and contact route? |
| A customer opens a useful document | Is the intended current document available or is the change explained? |
| A visitor submits a form | Does the correct team receive the complete request? |
Do not accept a screenshot as the only evidence for these checks. Follow the actual links and interactions in the release candidate. A page can be visible in a design presentation while its production address, document or form destination is still wrong. Keep a record of the tested URL and result so the same journey can be checked after deployment.
Protect the useful content while improving the design
A redesign is a good opportunity to make explanations clearer, but the team needs to know what information is being removed. Compare the current and proposed service descriptions side by side. Look for lost scope details, evidence, process explanations and answers to buying questions. Some text may deserve cutting; the decision should follow usefulness and accuracy rather than a desire to make every page fit the same visual height.
Check media as part of the content review. The new page may use a better hero image while accidentally losing a useful demonstration or project caption. Confirm which videos, photographs and documents support the service claim. Keep the company’s actual role visible. A more polished layout should not turn a specific, supportable project example into an unexplained decoration.
For multilingual sites, treat the second language as part of the release rather than a later cosmetic task. Match the service facts, examples and next steps across versions. Check links and confirmation messages as well as page paragraphs. If the English page changes materially while the German page retains the old offer, the business has created conflicting public explanations.
Give the launch a practical go-or-fix checklist
Agree which defects must be resolved before release and who can make that decision. A broken primary enquiry route is different from a minor spacing issue. The business and developer should identify the essential journeys and technical checks together. Keep the checklist short enough to use, with a clear result and responsible person for each item.
The release record should include the approved version, deployment time, major content or address changes and known limitations. Confirm who can investigate a problem immediately after launch and how the previous working state is available if a serious failure requires recovery. Ask the implementation team to explain that recovery process in terms the business can understand. Do not assume that a backup file alone establishes a tested recovery plan.
Once deployed, repeat the critical journeys on the live domain. Use the actual contact destinations with an agreed test message and verify receipt. Check the priority old links, the new service pages and language switching. Compare the live result with the acceptance record rather than assuming a successful deployment command proves the website is working for customers.
Investigate a post-launch problem by its symptoms
If enquiries fall while relevant visits remain similar, inspect contact controls, form delivery, service clarity and receiving-team records. If visitors arrive at the wrong destination, review the address map and campaign links. If a page is missing entirely, check the release inventory and implementation decision. These observations help narrow the investigation before anyone proposes another broad rewrite.
For search changes, use the available page and query evidence with the responsible SEO specialist. Preserve the release timeline and distinguish the redesign from concurrent campaigns, seasonal changes or other updates. A drop after launch deserves investigation, but timing alone does not establish which individual change caused it. The register makes the investigation more specific and the corrective action easier to verify.
Questions about redesigning an existing business website
Can an agency guarantee no search-visibility change?
Do not treat an absolute guarantee as a substitute for a migration plan. Ask for the inventory, approved content decisions, implementation checks and post-launch responsibilities. These are concrete deliverables the business can inspect. Search outcomes also depend on factors outside the redesign team’s direct control.
Should every old article be removed if the design is outdated?
No. Review the information and commercial purpose separately from its appearance. Useful content may need a new presentation, factual update or clearer links. Remove or combine pages when there is a reason, and record the intended treatment of existing visitors. Age alone does not tell you whether a page helps a buyer.
Who should own migration checks?
Assign a clear implementation owner and involve the people who can verify service facts, enquiry delivery and search configuration. The agency should explain which checks it performs and which inputs it needs from the business or another supplier. Shared work is manageable when responsibilities and acceptance evidence are explicit.
Assign the post-launch review
Name the person who investigates broken destinations, missing enquiries or unexpected search changes. Compare equivalent periods and account for seasonality, campaigns and other business changes. If a problem appears, use the register to identify what changed before making another broad redesign. Our web agency selection guide helps assess a provider's responsibilities; send your existing site and planned changes through our website page to discuss the scope.