A website redesign without losing SEO starts with clear decisions about which pages stay, which addresses change, and who proves the new site works.
You can protect useful content and reduce avoidable mistakes before anyone approves a new homepage.
If you run a commercial real estate brokerage, that means treating service pages, agent profiles, property details, and downloadable resources as part of the launch decision.
A polished screen alone cannot tell you whether those paths survived.
I create CRE websites, and I recommend separating design approval from permission to launch.
You can love the layout while still asking for proof that old links reach the right places.
No honest plan can promise that search visibility will stay exactly the same.
Google says significant site changes can bring temporary ranking fluctuations while pages are crawled and indexed again.
The practical goal is to prevent avoidable losses, keep useful information available, and spot problems early.
Here is a way to make those responsibilities clear before the project gets busy.
Want a redesign proposal that accounts for your existing brokerage pages?
Compare Website Design Pricing and bring your current site, planned changes, and migration questions to the discussion.
Launch approval needs separate evidence.
Before approving the redesign, ask for a written definition of what the team will check before launch.
The designer may control page layouts while a developer handles redirects and another company controls hosting.
Your brokerage still needs one person who can collect their evidence and decide whether the launch goes ahead.
I would give that person a simple approval record with the check, its owner, the result, and any unresolved issue.
An email saying everything looks good is too vague when three companies touched the website.
The record should separate visual approval, content approval, technical checks, and the final release decision.
A broker can approve the accuracy of a tenant representation page without having to judge server settings.
A developer can prove that an old address redirects correctly without deciding whether the replacement page explains the service well.
Give each person a clear task and a deadline that comes before the release window.
A launch rule should explain what stops the release.
For example, make a broken main contact route or an incorrect redirect from a priority service page a reason to pause.
A minor wording change on a low-priority page might be scheduled after launch if the broker agrees.
These are suggested project rules, so adapt them to your business and write down the exceptions.
Do not let an exception disappear inside a long email thread.
Record who accepted it, why it is acceptable, and when someone will fix it.
That small habit makes approval mean something you can review later.
The baseline should show what matters.
Ask the person responsible for measurement to save a dated view of the current website before major changes start.
Useful records include important landing pages, search queries, organic visits, and completed inquiry actions where those actions are already measured.
Review search performance in Google Search Console and record the date range and filters used.
For a site that uses Google’s measurement platform, review existing inquiry events in Google Analytics with the account owner.
Keep search clicks and recorded inquiries in separate columns because they answer different questions.
A visit is not a signed listing agreement, and a recorded event is not proof that the inquiry reached the broker.
I would also ask the brokerage which pages support conversations that matter even when their traffic is modest.
A specialized landlord service page could be important to a small group of owners.
Its value may not be obvious from a list sorted only by visits.
The comparison needs a written context.
Record any seasonal campaign, reporting change, or unusual listing activity that could affect the baseline.
If event tracking is missing or unreliable, say so rather than filling the gap with estimates.
Ask the measurement owner to explain which comparisons will remain possible after the redesign.
When the new site launches, a changed event name can make the reports look different even if the form still works.
Agree on the tracking definitions before that becomes an argument about the new design.
Your baseline gives the team a reference for investigation, rather than a promise about future traffic.
Every changed address needs a decision.
Create one shared record of existing page addresses and their intended destinations.
Start with the current website and sitemap, then add important landing pages and known links from campaign material or downloadable documents.
A sitemap is useful input, but it should not be treated as proof that every old address is included.
Ask the technical owner how the team will find pages that are missing from the main navigation.
For each address, record whether the page stays, moves, merges into another page, or is removed.
Include the proposed destination and the person who approves that choice.
Keeping an address stable can simplify the migration when the same useful page will remain available.
There is no need to rename every page just because the design changes.
For a permanent move, ask the developer to follow Google’s guidance on permanent redirects.
The replacement should meet the same need.
Suppose a fictional brokerage moves a landlord representation page into a new services folder.
The old address should lead directly to the relevant replacement rather than the homepage.
The broker should confirm that the replacement still answers the owner’s questions about that service.
Sending every retired address to the homepage can confuse readers and may be treated as a soft error by Google.
If content is truly gone and no suitable replacement exists, the technical owner should choose an appropriate error response.
Keep live properties, retired listings, service pages, and documents visible in this decision process.
They do not all deserve the same destination simply because they used the same old template.
Record disagreements before the developer turns the decisions into redirect rules.
Content approval should protect useful answers.
A redesign can keep the right address and still remove the information that made the page useful.
Assign a content reviewer who understands the brokerage’s actual services, territory, and current listings.
Ask that reviewer to compare important old pages with their replacements before approving them.
Look for useful explanations, relevant photos, accurate contact details, and links that help a reader take the next step.
I would keep a short list of content that must survive on each priority page.
For a landlord page, that might include the types of properties served, the markets covered, and the right inquiry route.
For an agent profile, it might include current responsibilities and a working way to reach that agent.
These are examples of review criteria, not a reason to preserve every sentence from an old website.
Outdated facts and duplicate material still need editing.
A merger should preserve the useful substance.
If two pages become one, have the reviewer name the distinct questions that the combined page must still answer.
A generic service summary may not replace a detailed explanation for a particular audience.
Check downloadable brochures and offering memorandums as part of the same review.
The link might work while the document contains an old phone number or an unavailable property.
Separate ownership of document updates from ownership of page layouts so each task gets done.
Need help organizing the material that belongs on your brokerage website?
Browse my Free Marketing Resources and use relevant materials to clarify what your readers need before approving page cuts.
The aim is a clearer site that preserves useful answers and removes stale material for a documented reason.
Technical checks need a named owner.
Ask the developer to document how redirects, canonical addresses, internal links, and indexing settings will be checked.
A canonical address tells search engines which version of a page the site prefers.
It should point to the intended public page rather than an old address or a private test site.
Internal navigation should also link directly to the final addresses wherever practical.
Readers should not need to pass through a redirect every time they open a main service page.
The technical owner should check response codes as well as what appears in the browser.
A page that looks normal can still send an unexpected response to search engines.
Record a sample of important pages across the templates that the redesign changes.
Include a service page, an agent page, a property detail page, and a document link when those features exist.
Testing controls need a release check.
Development sites often use access controls or indexing restrictions to keep unfinished work out of search results.
The release plan should name the person who removes restrictions that must not remain on the public site.
Ask them to verify both page-level indexing directives and relevant site-level settings.
Google’s site migration guidance specifically addresses preparing indexing controls and URL changes.
After launch, inspect representative public addresses with the URL Inspection tool.
Its live test can help assess the current page, while the indexed result describes what Google has recorded.
A successful live test does not guarantee that Google will index or rank the page.
Save the tested address, result, and date so the approval record contains evidence someone can revisit.
The release plan should cover real inquiries.
Before setting a launch time, agree on who will test the website from a prospective client’s point of view.
Start on a priority service page, follow its links, and send a clearly marked test inquiry.
Ask the intended recipient to confirm arrival rather than trusting the success message on the screen.
Check the actual form fields, the recipient, and the next step the page promises.
For a brokerage with separate teams, test more than the main contact form.
A property inquiry could go to a listing agent while a general owner inquiry goes to an office manager.
Use test information that the team can recognize and remove from normal follow-up work.
I would assign the brokerage contact to confirm receipt and the technical owner to fix any delivery failure.
Recovery work should have an owner too.
Ask the hosting or development team to explain the backup and recovery process before launch.
Name the person who can authorize a recovery and the person who can carry it out.
A recovery plan should account for inquiries or content changes received after the new site goes live.
Restoring an older copy without considering those changes can create another problem.
Also agree on who checks the public website immediately after release and who remains available if something breaks.
Want a visual reference while reviewing page structure and the next step for visitors?
Explore my Helpful Video Walkthroughs and Tools and bring questions about your own pages to the project discussion.
Videos can help you frame a question, but your team’s launch record should contain the actual test results.
Follow-up should close the approval record.
The job is not finished when the new homepage loads on the designer’s computer.
Agree on follow-up checks for the first working day, the next week, and later reporting reviews.
These are suggested review points, not a forecast of when search performance will settle.
Assign someone to review important redirects, missing pages, inquiry delivery, and changes in search reporting.
Use comparable date ranges where possible and keep track of any measurement changes.
One quiet day does not establish that the redesign caused a lasting decline.
A broken priority page still deserves prompt attention even when the overall traffic report looks fine.
I would keep a short issue log with the affected address, the evidence, the owner, and the next action.
Redirect upkeep should remain part of the agreement.
Google recommends keeping redirects for as long as possible, generally at least one year, during URL moves.
Its guidance also notes that keeping them indefinitely can help users who still follow older links.
Ask who maintains those rules after the project ends and what happens if hosting changes again.
A redirect that works today is only useful tomorrow if someone preserves its configuration.
For website redesign without losing SEO, that ongoing ownership matters as much as the launch checklist.
Close an issue only after the assigned person retests the affected page or inquiry route.
Ready to define a redesign around your brokerage’s pages and launch responsibilities?
Review Website Pricing and ask which migration tasks, testing duties, and follow-up work belong in your proposed scope.
A clear agreement gives everyone a practical way to decide when the new site is ready.
Common migration questions have practical answers.
Can a website redesign without losing SEO be guaranteed?
No redesign can guarantee unchanged search visibility.
A careful migration can reduce avoidable mistakes, but Google may reassess pages and rankings can fluctuate while the changed site is crawled and indexed.
Who should approve redirects before a CRE website launch?
The brokerage should approve the business relevance of each important destination, while the technical owner implements and tests the redirect rules.
One project lead should collect that evidence before authorizing launch.
Do all page addresses need to change during a redesign?
No, useful pages can often keep their existing addresses when only the layout changes.
Change an address for a clear reason, and document the destination and redirect when a permanent move is needed.
How long should old page redirects stay active?
Google recommends keeping migration redirects for as long as possible, generally at least one year.
Keeping them longer can help people who follow older links, so assign ongoing responsibility for their upkeep.
What should the brokerage test after the new site launches?
Test priority page destinations, useful content, and inquiry delivery to the intended recipient.
Review public indexing settings and search reporting with the assigned technical and measurement owners, and keep unresolved issues in a shared record.
