Site Renewal Case Study: Miyazaki Trucking Company Douzu Carry Service — What We Carried Over from the Old Site, and How

· · Website Development, SEO, Existing Site Improvement, Site Renewal, Case Study, Local SEO

The scariest thing about a site renewal is when, in exchange for a fresh new look, your search rankings and inquiry flow quietly break. This article uses the renewal project for Douzu Carry Service, a trucking company in Miyazaki, as a case study, and walks through what we locked down before touching the design.

When people talk about a site renewal, the conversation usually starts with design mock-ups or what the homepage should look like. But when the old site already has meaningful search traffic and backlinks, there are things you need to settle before the design — things that are hard to walk back later. Those are URL design, and how to carry over the information on the old site.

This article uses the renewal of Douzu Carry Service — a Miyazaki-based trucking company handling single-item moves, long-distance delivery, and refrigerated/frozen transport — as a case study, and summarizes the actual steps we followed. A brief overview is available in the case study covering Douzu Carry Service’s structure, but this article digs a bit deeper into the details.

Note that this article doesn’t include measured-effect numbers such as changes in visit counts or inquiry volume. What we’re able to lay out here are only the facts of what was done and in what order — effect metrics simply aren’t part of the source material for this article.

1. Project Overview — Before / After

First, the big picture.

Item Before (old site) After (new site)
Implementation Static HTML + PHP (including a form-submission script) Static site generation (a build script generates pages from Markdown) + Cloudflare Pages
Domains douzucarry.com plus several separate domains scattered across old landing pages Consolidated onto douzucarry.com
Blog A mix of auto-generated ID-based URLs (e.g., /blog/dgrd0d8_ssb/) and date-stamped .html filenames Unified into meaningful-slug URLs (managed as Markdown in the repository)
Inquiry flow Phone, email, and a LINE quote request, plus an unused form-submission script left behind Consolidated into /contact/

The main static pages — home, services list, moving, refrigerated/frozen delivery, same-day delivery, senior-facility relocation, pricing, company information, FAQ, and contact — along with the nine area pages for Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, and Ebino, all kept their URLs unchanged through the renewal. What mainly changed was the handling of the old blog’s meaningless URLs and an unused leftover script.

On top of that, the new site’s design was built on the design system published by Japan’s Digital Agency. Skipping the step of building a design from scratch let us put that saved effort into the URL design and content migration work covered in this article. The thinking behind this approach is laid out in “Why KomuraSoft Builds Websites on the Digital Agency Design System — Low Cost and High Quality Can Coexist.”

If there’s one point to take away from this case, it’s this: we finished the URL and content inventory before touching the visual design, and only then got started. The chapters that follow walk through that process step by step.

2. The First Step Wasn’t Design — It Was a URL Inventory

The first thing we produced when kicking off the renewal wasn’t a rough design draft — it was an inventory table listing every URL on the old site.

Specifically, we exhaustively catalogued the following units.

  • Static pages (home, services list, moving, refrigerated/frozen delivery, same-day delivery, senior-facility relocation, company information, privacy policy, FAQ, pricing, blog, contact)
  • The nine area pages (Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, Ebino)
  • Individual posts on the old blog (over 100, ranging from area-focused columns to know-how articles on single-item and long-distance moves)
  • “Files that aren’t pages but are still publicly accessible,” such as robots.txt, sitemap.xml, the Search Console ownership-verification file, and the old form-submission script (php/submit.php)

Only once this inventory table existed could we build a mapping table that decided, URL by URL, what should happen to it on the new site. In this project’s mapping table, we split the decision into two broad categories.

Decision Meaning Examples
keep Leave the URL unchanged /, /moving/, /area/miyazaki/, current blog post URLs, etc.
redirect 301-redirect to a new URL The old blog’s auto-generated ID URLs, date-stamped .html filenames, php/submit.php

The static pages, the area pages, and the currently meaningful blog post URLs were all set to keep (unchanged). On the other hand, meaningless, system-auto-numbered random-string URLs (things like /blog/5lmln1lx0x/) and date-stamped filenames like post20210721.html were designed to 301-redirect to new article URLs carrying a meaningful slug.

One more thing that fell under this decision-making process was php/submit.php, a submission-target script left over on the old site. We confirmed it wasn’t referenced by any form in the published HTML, and that the inquiry channels actually functioning were only the three systems of phone, email, and the LINE quote request — so we judged it to be a “leftover submission script” and set it to 301 to /contact/. (We cover the background to this decision in more detail in the next chapter and Chapter 5.)

For the redirect design, we enforced two rules without exception.

  • Resolve every redirect in a single hop (never create a chain of redirects)
  • Build in a check at build time that verifies the destination URL actually exists (to prevent the accident of a 301 pointing to a URL that doesn’t exist)

Locking down this inventory and mapping table before even considering the design means that the later stages of implementation and content creation can proceed on the solid foundation of “what goes on which URL,” which reduces rework. This isn’t specific to this one project — it’s a basic procedure that applies just as directly to any renewal of an old site that already has backlinks or search traffic.

3. A Retention Checklist for Not “Dropping” Content

Alongside the URL design work, we built a content-retention checklist to confirm that all the information written on the old site could still be reproduced without exception on the new one.

In a renewal, small selling-point copy and numbers can quietly disappear in the process of refreshing the design. If information that directly drives inquiry decisions — pricing, business hours, contact details, key strengths — is what gets dropped, it can lead to the very outcome where the site looks better but inquiries actually drop.

So we wrote out the must-keep information from the old site for each major page. Here’s some of what that included.

Page Key elements that had to be retained
Home (/) Single-item moves from ¥8,000, daily service between Miyazaki and Osaka, LINE quote request, ¥3,000 discount, open year-round 8:00–20:00, phone number, guidance on reviews, ratings, and insurance
Moving (/moving/) ¥13,500 for 2 hours / from ¥8,000 at the cheapest, single-item / family / office relocation, large-item transport and furniture placement, unwanted-item removal, night/early-morning service, specially equipped high-roof vehicles
Pricing (/price/) Three plans — Budget Simple from ¥8,000, Easy from ¥19,800, Effortless from ¥29,800 — plus the approach to load volume, staffing, area-based rates, and options
Company information (/company/) Representative Kiyoshi Dozu, 20+ years in the moving industry since his teens, delivery from Miyazaki nationwide, breadth of service area
FAQ (/faq/) Cancellation fees, advance provision of packing materials, special handling for art and Buddhist altars, requests starting from a single box, ways to keep long-distance costs down, and more
Refrigerated/frozen delivery (/refrigerated/) Vehicles equipped with −20°C freezer units, temperature-controlled transport for food, pharmaceuticals, and research materials, 24/7/365 availability, scheduled and route delivery
Senior-facility relocation (/senior/) Moves into elder-care facilities, packing / unpacking / cleaning / unwanted-item disposal, support for care beds, wheelchairs, Buddhist altars, and accompanying pets

With this checklist in hand, we cross-checked the old and new pages one by one before launching the new site, confirming that no elements had been dropped. The key point is that we guaranteed, via a list rather than intuition or memory, that the “decision-making material” — pricing, business hours, strengths — carried over intact even though the design had changed.

4. Local SEO — Designing the Nine Area Pages

Among the pages carried over from the old site are nine individual pages, one for each of the following areas: Miyazaki, Miyakonojo, Nobeoka, Nichinan, Kobayashi, Hyuga, Saito, Kushima, and Ebino.

These area pages exist as a landing point for search queries that include a place name, such as “[place name] + moving” or “[place name] + delivery.” For a service like trucking or moving, where the trade area is tied to specific regions, they play the role of capturing place-name search demand that the homepage or pricing page alone can’t fully catch.

Looking at the URL mapping table, all nine pages from /area/miyazaki/ to /area/ebino/ were judged keep (no URL change), and the renewal didn’t touch this structure itself. Alongside them, there are also numerous blog posts tied to each area that cover specific local place names — the districts within Miyazaki City or Miyakonojo City, for instance — forming a structure where the area pages and blog posts complement each other.

Pages like these area pages — the type produced by mass-varying only the place name in an otherwise identical format — run the risk of looking, to both search engines and readers, like reused copies of the same page if the content is thin. In this case, the division of labor was carried over from the old site: the area pages themselves handle the area level, while the blog posts individually cover district-level detail within each area. That structure already avoided the “thinness” typical of mass-produced pages. The renewal left this structure intact and kept the URLs unchanged.

5. Consolidating Scattered Inquiry Channels

How we handled php/submit.php, mentioned in Chapter 3, was also an important decision from the standpoint of organizing the inquiry flow.

Investigating the old site, we confirmed that only the following three systems were actually functioning as publicly available inquiry channels.

  • Phone (0120-931-677, reception hours 8:00–20:00)
  • Email
  • LINE quote request

On the other hand, the submission-target script php/submit.php itself remained in the code but wasn’t referenced by any form in the published HTML. In other words, it was a “leftover script” that wasn’t actually being used. Based on that, the new site consolidates the three channels — phone, email, and the LINE quote request — onto the /contact/ page, and any access to php/submit.php is designed to 301 to /contact/.

When inquiry channels are scattered across multiple pages and scripts, it’s easy to lose track, right around renewal time, of which ones are actually in use. This approach — first identifying which channels are actually functioning, then consolidating them, as we did here — also holds up as a general principle for reviewing the flow between a homepage, service pages, and a contact page. We’ve also covered this idea in an earlier article, “The Three Places to Fix First on a Site That Gets No Inquiries,” which is worth a look as well.

6. Cleaning Up Old Domains — Handling an Abandoned Landing-Page Domain

Companies like trucking firms that have built separate landing pages for each service sometimes end up, without quite noticing, with their domains scattered across several places. In this case too, we needed to sort out the following domains.

Domain Status Response plan
www.douzucarry.com Serving duplicate content identical to the apex domain (douzucarry.com) with a 200 status Plan a 301 to the apex domain via Cloudflare Redirect Rules
A Japanese-character domain (in punycode form) Already 301-configured to douzucarry.com Already handled, kept as-is
The old landing-page domain for refrigerated/frozen delivery Cannot resolve, likely because its DNS has lapsed The content itself has already been migrated to /refrigerated/. The constraint remains that a 301 on the domain side can’t be set up unless the domain is recovered

The third case in particular is an important lesson. The content of the old refrigerated/frozen delivery landing page — its selling points around −20°C freezer-equipped vehicles, 24/7/365 availability, and scheduled/route delivery — has already been migrated to /refrigerated/ on the new site. But because the old domain itself can no longer resolve, likely due to a lapsed DNS registration, there’s no way to set up a 301 redirect from it. The lesson is that if you leave a domain unmaintained and unrenewed, you risk suddenly losing, one day, the backlink authority and branded-search traffic that had built up on it.

If your company operates service landing pages on separate domains and is considering a renewal, we’d recommend not just deciding where the content will be consolidated, but also checking, at the same time, the old domain’s contract status — whether renewal is still active and whether its DNS is still alive. Whether or not you can still set up a 301 while recovery is possible makes a real difference to how easily the accumulated authority can be carried forward afterward.

7. Pre-Launch Verification and Post-Launch Tasks

Before launching the new site, we ran through the following checks.

  • Cross-checking against the content-retention checklist built in Chapters 2 and 3 (whether the old and new pages have matching elements)
  • Live verification of the 301 redirects (actually sending requests and confirming they return the expected status codes and destinations)
  • Confirming the Search Console ownership-verification file correctly returns a 200
  • Confirming that files required for launch, such as robots.txt, sitemap.xml, and _headers, are actually published

There are also tasks to handle after launch.

  • Resubmit sitemap.xml to Search Console
  • Use the URL Inspection tool to individually confirm that the old blog’s ID-based URLs and date-stamped .html filenames are 301-ing as expected
  • Over the course of several weeks, check the Coverage report to see whether old URLs that were previously 404 or excluded from the index come to be recognized as “Redirect”

A renewal project doesn’t end at launch — it’s worth planning around the premise that it’s only truly complete once you’ve monitored the redirects and confirmed the search engine has properly recognized them after launch.

8. Summary — General Rules for Not Failing at a Renewal

Distilling the thinking from this Douzu Carry Service case into ideas that apply equally to other renewal projects gives us the following.

  • URL design comes first, design comes after. For an old site with existing search traffic or backlinks, finalize the full URL inventory and the mapping table for the new URLs (301 mapping) before you even consider the visual design.
  • Don’t launch without a content inventory. Confirm “decision-making material” like pricing, business hours, contact details, and strengths with a checklist that cross-checks the old and new pages one by one, before launching.
  • Keep only the channels that are actually in use. If you find an unused form or submission script, verify what’s actually going on, then consolidate it into the channel that’s still live.
  • Pair every redirect with a single hop and destination-existence verification. Never create chains, and have a mechanism in place that won’t send anyone to a URL that doesn’t exist.
  • Clean up domains while they’re still alive. Leave a separate domain for a service landing page unmaintained, and a lapsed DNS registration can make it unrecoverable — costing you the very opportunity to carry forward its accumulated authority.

A site renewal isn’t simply the work of refreshing the design — it’s also a design task in its own right: figuring out how to carry forward the search authority and inquiry flow you’ve built up over time. A concise overview of this case is summarized in “the case study covering Douzu Carry Service’s structure,” which is worth a look as well.

If you have similar concerns about URL design or carrying over existing content, we can work through the old site’s inventory together as part of a website development consultation.

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

These topic pages place the article in a broader service and decision context.

This article connects naturally to the following service pages.

Website Development

This is a real-world example of URL design and content migration during a site renewal, so it connects directly to consultations about similar renewal projects.

Frequently Asked Questions

Common questions about the topic of this article.

What should a site renewal start with?
Not a design mock-up, but an inventory table listing every URL on the old site. This means exhaustively cataloging static pages, area pages, and blog posts, plus "files that aren't pages but are still publicly accessible," such as robots.txt, the Search Console ownership-verification file, and form-submission scripts. From there, you build a mapping table that decides, URL by URL, whether it should be kept unchanged or redirected (301). Locking down this foundation first reduces rework later in implementation and content creation.
What are the key points of redirect design for avoiding a drop in search rankings during a renewal?
Keep meaningful URLs — static pages, area pages, and so on — exactly as they are, and only 301-redirect the meaningless, system-auto-numbered URLs to new URLs that carry a meaningful slug. As design rules, we enforce two things without exception: every redirect resolves in a single hop with no chains, and the build includes a check that verifies the destination URL actually exists, to prevent the accident of 301-ing to a URL that doesn't exist. After launch, we monitor Search Console for several weeks until it recognizes the redirects.
Why does a renewal sometimes end up causing inquiries to drop?
Because during the process of refreshing the design, information that directly drives an inquiry decision — pricing, business hours, contact details, key selling points — can quietly get dropped without anyone noticing. As a countermeasure, we build a content-retention checklist that writes out the must-keep information from the old site for each major page (pricing plans, reception hours, services covered, etc.), then cross-check the old and new pages one by one before launch. The key is guaranteeing this with a list rather than relying on memory or a gut feeling.
Is it fine to leave an unused landing page on a separate domain alone?
Leaving it alone is risky. In this case, the old landing-page domain for refrigerated/frozen delivery could no longer resolve, likely because its DNS had lapsed — and even though the content had already been migrated to the new site, there was no way left to set up a 301 redirect from the old domain. Leave a domain unmaintained and unrenewed, and one day you can suddenly lose the backlink authority and branded-search traffic that had accumulated on it. When considering a renewal, check both the old domain's contract status and whether its DNS is still alive at the same time, and set up the 301 while recovery is still possible.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.

Back to the Blog