Site Renewal Case Study: Miyazaki Trucking Company Douzu Carry Service — What We Carried Over from the Old Site, and How
· Go Komura · 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)
- 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.xmlto Search Console - Use the URL Inspection tool to individually confirm that the old blog’s ID-based URLs and date-stamped
.htmlfilenames 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.
Related Articles
Related Articles
Recent articles sharing the same tags. Deepen your understanding with closely related topics.
Make Your Site Show Up for Local-Name Searches — A Practical Local SEO Guide for SMEs (Area Pages and Google Business Profile)
For SMEs whose site doesn't show up when someone searches 'area name + industry.' This article lays out the order in which to fix local S...
The Three Places to Fix First on a Site That Gets No Inquiries
For a site where inquiries have stalled, we organize the issues to fix first on the top page, service pages, and contact page, by the poi...
Why a Technical Company's Website Fails to Communicate What the Company Does
We examine why technical and B2B websites fail to convey what the company actually does, looking at the division of roles between the top...
Running Google Ads on a Small Budget for BtoB — How to Design and Run a Weekly Routine That Delivers Results on a Few Tens of Thousands of Yen a Month
A practical guide to Google Ads for BtoB companies wanting to start with a budget of just a few tens of thousands of yen a month. Covers ...
Getting More Inquiries on a B2B Website — A Complete Roadmap of What to Fix First, from Acquisition to the Form
When inquiries on a B2B website stall, most companies start by working on acquisition (SEO and ads). But what actually moves the needle i...
Related Topics
These topic pages place the article in a broader service and decision context.
Windows Technical Topics
Topic hub for KomuraSoft LLC's Windows development, investigation, and legacy-asset articles.
Web Development & SEO Topics
Topic hub for website development, SEO, inquiry flow, and internal-link design.
Where This Topic Connects
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.
Public links