A new website can look ready while old links still lead nowhere. A customer opens last month's estimate, scans a printed code, or follows a saved service page—and misses the information they wanted.
Before approving the launch, ask where each important old address will send that customer.
For a Tempe business updating its website, this is a practical part of the move. You do not need to configure the server yourself. You do need a clear list, someone responsible for it, and evidence that the route works.
Decide which addresses need to change
A new design does not automatically require new page addresses. Ask your developer to separate the visual changes from changes to the domain or the part after it.
For example, changing a heading on a service page is different from moving that page to another address. Renaming a navigation label does not necessarily require renaming its destination.
Keep useful addresses where you can. If a move is necessary, write down why: a clearer service structure, a platform requirement, or a business change.
Our service-page guide can help you decide what each page should explain. Settle that purpose before deciding where an old page belongs.
Google recommends mapping old URLs to their new destinations when addresses change. Its migration guide also recommends updating internal links and the sitemap to the new addresses. Read Google's site-move guidance.
Collect the links your business already uses
Ask for an export or crawl of the existing site before it is replaced. Then add the links that matter outside the website menu.
Look through recent proposals, email templates, paid campaign destinations, booking links, printed materials, and downloadable documents. Ask the person answering inquiries which links they send most often.
A small page can still matter if it appears on every estimate. Traffic totals alone do not explain that importance.
Record the current address, its purpose, the planned destination, and who will check it. Keep the full address in the working record so the team can distinguish different domains and versions.
- Current address
- Copy the complete link customers already have.
- Customer task
- What information or action were they looking for?
- Planned destination
- Record the relevant new page, or the retirement decision.
- Verified by
- Name the checker and record the result and date.
Imagine a Tempe repair business moving its equipment-service page. A customer opening that link from an old quote should reach the relevant service information, not be left to search the entire new site.
Use that customer's task as the test. Can they still understand the offer, check the details, and take the intended next step?
Agree on moved, merged, and retired content
Not every old page needs the same treatment. Discuss the destination before someone adds a blanket redirect rule.
If content is moving permanently, Google recommends a permanent server-side redirect where possible. The technical status codes are 301 and 308. These tell browsers and search engines that the page has moved. Google explains permanent and temporary redirects.
Your developer can choose the implementation for the platform. Your part is confirming that the destination answers the same customer need.
If several old pages become one stronger page, read the combined page. Does it still cover the information people expected from each old link?
If an offer or document has genuinely been retired with no replacement, say so in the plan. A missing page should return an appropriate response, such as 404 or 410, rather than pretend to be a successful page. Google documents how these status codes are handled.
Give visitors a useful explanation and a route to current services where appropriate. That is different from silently sending every missing address to the homepage.
Same purpose, new address. Confirm the destination.
Several pages, one destination. Check that it covers each need.
No replacement. Explain what is gone and offer useful next steps.
Test from an old link before signing off
Do not start every test from the new homepage. Open the old addresses directly, just as a returning customer would.
Ask the developer to verify the full list automatically, including the response and final destination. Then manually review the important customer routes on a phone and a larger screen.
For each priority link, check the page title and service details. Follow the contact or booking action. Open the document if that was the original destination. A page loading successfully is only part of the test.
Test any printed QR code you still distribute. The printed square contains a destination; changing the design of your website does not change what is printed on paper.
Our website checks before advertising cover testing the inquiry path. Use that same care for links in campaigns that will remain active after launch.
Keep a short launch record: what was checked, which version was checked, what failed, and who owns the fix. Agree in advance which failures would delay launch, such as a broken primary booking route.
Separate a live page from an indexed page
A customer test and a search check answer different questions. First establish that the public page works. Then ask your developer to review how Google sees the important new addresses.
Search Console's URL Inspection tool distinguishes indexed information from a live test. A successful live test does not guarantee indexing or appearance in search results. It also does not test every possible indexing condition. See Google's URL Inspection guidance.
Keep those results labeled in your launch notes. “The page works,” “Google can access it,” and “the new address appears in search” are different observations.
Google notes that significant site changes can cause temporary ranking fluctuations during recrawling and reindexing. Its site-move guide recommends keeping redirects as long as possible, generally at least a year. Review the migration guidance.
Treat that as a planning baseline, not a reason to remove useful redirects on an anniversary. Old proposals and printed materials may still be in circulation.
Keep responsibility after launch
Name the person who will review reported broken links and important customer routes after the move. Give staff a simple way to forward a failing address with a description of what the customer expected.
If the domain itself changes, include continued control of the old domain in the plan. Ask how redirects will be kept working and which service owns them. Do not cancel the old arrangement until those responsibilities are clear.
Our website handover checklist covers access, renewals, and support. Include the address map and launch record in that handover so the next person can understand the decisions.
A useful website launch leaves your team able to answer a basic question: where did this page go?
Planning a change? Our technical SEO service can help review the route from old addresses to new pages. Tell Brandon what is changing on your website.
