“Our old bookmarks stopped working” — A practical URL handover process for site redesigns

“My old bookmark doesn’t work anymore.”

For directors at production agencies, this is one of the messages you do not want to receive a few days after a site redesign goes live.

The design was approved.
The build was completed.
The main pages looked fine.
The launch itself seemed to go smoothly.

But then a client checks a page they used to visit often, and it no longer opens. When you look at Google Analytics, organic search traffic has dropped after launch. Lower-level pages that had been bringing in visitors are now sending people to 404 errors.

In a redesign, “the new site is live” and “the old site has been properly carried over” are not the same thing.

Especially when the URL structure changes, old URLs need to be handed over carefully to new URLs with 301 redirects. If that handover is incomplete, the search traffic, bookmarks, and familiar routes customers have built up can snap on launch day.

We have felt this risk ourselves in redesign projects. That is why we started treating URL handover not as a final pre-launch check, but as an operational process that begins much earlier.

This article explains the steps we use to reduce missed redirects during site redesigns.

---

Why this problem happens

Broken bookmarks and post-redesign 404s are often described as simple confirmation misses. But in practice, the problem is more structural.

During a redesign, visible tasks tend to take priority: design, development, content migration, staging checks, and launch work. Compared with those, old URL handling can feel like a background task.

But for users, old URLs are familiar paths.
For search engines, they are locations where traffic and evaluation have accumulated over time.

When those addresses change without a clear handover, the redesign may look successful on the surface while important access routes are quietly cut off.

Background 1: lower-level pages are easy to miss when only main pages are checked

A common pattern is to manually redirect only the obvious pages.

The homepage is checked.
The contact page is checked.
The main service pages are checked.

Those pages matter, of course. But the pages most likely to be missed are often lower-level pages: detailed service pages, old article pages, campaign pages, or pages that client-side stakeholders had bookmarked.

If these pages had organic search traffic or were used frequently by customers, missing their redirects can create problems right after launch.

The dangerous part is that the site may look fine when you only click through the main navigation. The gaps are hidden deeper.

Background 2: without an old-to-new URL mapping, fixes become difficult later

The second issue is the absence of a clear mapping.

Which old URL should forward to which new URL?
Which pages should be merged?
Which pages should be retired?
Which old pages no longer need redirects?

If these decisions are not listed somewhere, the team has to reconstruct them after problems appear.

By that time, the old site may already be close to being taken down. Rebuilding the mapping afterward can take days. Without a record, it is hard to notice the gaps, assign fixes, or prioritize what matters most.

---

Steps to prevent missed URL handovers

To reduce URL handover misses, we organize the process around three steps: making the current state visible, turning checks into repeatable operations, and confirming recovery after launch.

STEP 1: Make the current state visible

The first step is to list the old URLs.

In our projects, we keep an old-to-new URL mapping register in the project Wiki. The format is simple:

• Old URL
• New URL
• Whether a redirect is needed
• Owner

The important point is timing. We do not start this right before launch. We begin creating the register during the redesign planning and design stage.

This makes it easier to discuss questions such as:

• Where should this old page lead in the new site?
• Should this page be merged into another page?
• Is this page safe to retire?
• Who is responsible for making the final decision?

With MONJI+’s Wiki feature, project information like URL mappings can be kept in one place. This helps the team trace what was decided, by whom, and how far the handover work has progressed.

STEP 2: Turn pre-launch checks into a repeatable checklist

Next, we turn the pre-launch confirmation process into a checklist.

URL handover is not something we want each project member to remember from scratch every time. A fixed checklist makes it easier to repeat the same checks across projects and reduce person-by-person variation.

For redesign launches, we check items such as:

1. Has every old URL been reviewed for whether a redirect is needed?
2. Are the redirect destinations for key paths, such as the homepage, contact page, and main services, correct?
3. Has sitemap.xml been updated and submitted with the new URL structure?
4. Have noindex and staging settings been removed at launch?
5. Are there any multi-hop redirect chains, such as A → B → C?

We register these items in MONJI+’s Checklist feature, so they can be called up directly when creating Feedback.

We also combine human checks with mechanical detection. With MONJI+’s website issue detection, entering a URL lets the system crawl the site and detect 404s and broken links. Detected issues can then be routed into Feedback.

Because it can also cover desktop and mobile display differences, as well as Basic-auth staging environments, it helps us find remaining holes before launch.

STEP 3: Confirm after launch whether traffic has recovered

The work does not end when the site goes live.

After launch, we check whether organic search traffic is coming back. If some pages remain down, we prioritize additional redirects for those pages.

In MONJI+, the Google Analytics integration lets us check access data within the project. When we find something that needs action, we turn it into a Feedback item with an owner, due date, and priority.

This prevents post-launch fixes from becoming vague tasks like “someone should look at this.”
Feedback with upcoming due dates appears on the My Page dashboard, so the team can see what still needs to be handled after launch.

For client communication, we can also share only the in-progress Feedback items through a public link. This reduces the need to repeatedly explain the current status in meetings or messages.

---

What changed in practice

By keeping the old-to-new URL mapping as a register, turning checks into a checklist, and monitoring traffic after launch, our post-redesign operations became easier to manage.

Previously, when something broke after launch, we first had to investigate which old URLs had been missed. Now, the mapping register gives us a clear place to start.

404s and broken links can be detected through website issue detection, and items that need action can be managed as Feedback. This reduces situations where someone notices a problem individually, sends it somewhere, and then the team is unsure who is handling it.

After launch, checking organic traffic in numbers also helps us avoid ending the project based only on the feeling that “the site seems fine.” We can look at whether access is actually returning and decide where to act first.

---

Notes and limitations

That said, the process does not make every decision automatic.

A tool can help detect 404s and broken links.
It can help manage the URL mapping.
It can help standardize checks and organize Feedback.

But it does not decide which old pages are worth keeping, which should be merged, and which should be retired.

That judgment still belongs to the people who understand the site’s intent, history, and traffic. A redirect is not just a technical setting. It is also a decision about how to carry over the value built up through past operations.

So we draw a clear line.

We let the system help us find gaps, organize checks, and manage fixes.
But we keep the final decisions, such as “keep this page” or “fold this page into that one,” in our own hands.

Redirect handover is not glamorous work. But it is important work for protecting the traffic and trust that have been built up before a redesign.

---

MONJI+, the WebOps platform born from the field

A redesign handover involves many small but important tasks.

Mapping old URLs to new URLs.
Checking redirects before launch.
Detecting 404s and broken links.
Confirming traffic after launch.
Managing each fix with an owner and due date.
Sharing progress with clients.

MONJI+ was born to support these kinds of real website operation workflows.

MONJI+ brings the people involved in website operation together into one team, and works across every phase of website operation to solve their challenges.

From the start, we have never aimed to build a “finished product.”

The challenges truly worth facing are in the field of website operation. That is why we have continued to listen to the real voices of people working there.

Taking in each voice one by one, we have layered on updates that resolve small points of friction, and new features have grown out of the field’s challenges. Through that accumulation, MONJI+ has become supported by users across 77 countries.

▼ Learn more about MONJI+ here
https://monji.tech/plus/

A world where the people working in website operation can say, with pride, “I love this work.”
▼ To make that real, we are waiting to hear your voice
https://monji.tech/plus/co-creation/

---

Summary

A site redesign often puts the spotlight on the new design. But if old URLs are not handed over properly, search traffic and bookmarks that were built up over time can be cut off on launch day.

The risk is especially high when only main pages are redirected by hand and lower-level pages are left unchecked.

To prevent this, start building an old-to-new URL mapping during the design stage, not at the last minute. Turn pre-launch checks into a checklist. Use issue detection to find 404s and broken links. After launch, confirm whether organic search traffic is coming back.

And most importantly, keep the design judgment in human hands.

Which pages should remain?
Which should be merged?
Which should be retired?

Those decisions should be made by the team that understands the site’s purpose and history.

Before a redesign erases your customers’ familiar pages, treat URL handover as part of the redesign process itself.