Кейс обновления сайта: транспортная компания Douzu Carry Service из Миядзаки — что и как перенесли со старого сайта

Самое опасное в обновлении сайта — ситуация, когда внешний вид стал новым, а позиции в поиске и путь к обращению тихо сломались. На примере транспортной компании Douzu Carry Service из Миядзаки разбираем, что мы зафиксировали до того, как взялись за дизайн.

Когда говорят об обновлении сайта, разговор часто начинается с макетов или с того, как должна выглядеть главная. Но если у старого сайта уже есть поисковый трафик и обратные ссылки, есть вещи, которые нужно решить раньше дизайна: иначе потом их почти не откатить. Это проектирование URL и то, как перенести информацию со старого сайта.

Статья описывает, как мы на практике обновляли сайт Douzu Carry Service — транспортной компании из Миядзаки, которая занимается переездами для одного человека, дальними перевозками и рефрижераторной доставкой. Краткий обзор есть в материале «Организация сайта Douzu Carry Service»; здесь тот же кейс разобран подробнее.

Цифр эффекта — изменения посещаемости или числа обращений — в статье нет. Здесь только факты: что сделали и в каком порядке. Цифр эффекта в источниках этой статьи нет.

Что можно взять из статьи — шаблон процедуры, который можно перенести на своё обновление. Четыре конкретные вещи: состав колонок таблицы URL и таблицы соответствий (глава 2), как реализовать 301-редиректы и примеры настроек (глава 3), как составить чек-лист сохранности контента (глава 4), команды проверки и пункты контроля до и после запуска (глава 8). Читать стоит с вопросом: «если делать то же на нашем сайте, что подготовить и что проверить».

1. Обзор проекта — до / после

Сначала общая картина.

Основные постоянные страницы — главная, список услуг, переезды, рефрижераторная доставка, доставка в день заказа, переезд в учреждение, цены, о компании, FAQ, контакты — и девять региональных страниц (Миядзаки, Мияконодзё, Нобеока, Нитинан, Кобаяси, Хюга, Сайто, Кусима, Эбино) после обновления сохранили те же URL. Изменилось в основном обращение с бессмысленными URL старого блога и с неиспользуемым скриптом, который остался в коде.

Дизайн нового сайта собран на основе дизайн-системы, которую опубликовало Цифровое агентство Японии (Digital Agency). Этап рисования дизайна с нуля мы опустили и направили это время на проектирование URL и перенос контента, о которых речь ниже. Логика такого подхода изложена в статье «Почему KomuraSoft делает сайты на дизайн-системе Цифрового агентства Японии».

Если свести кейс к одной фразе: мы сначала закончили инвентаризацию URL и контента и только потом взялись за внешний вид. Дальше — по шагам, как это делали.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Первым делом был не дизайн, а инвентаризация URL

Первое, что мы сделали в начале работ, — не черновик макета, а таблицу, в которой перечислены все URL старого сайта.

Конкретно без пропусков выписали следующее.

• Постоянные страницы (главная, список услуг, переезды, рефрижераторная доставка, доставка в день заказа, переезд в учреждение, о компании, политика конфиденциальности, FAQ, цены, блог, контакты)
• Девять региональных страниц (Миядзаки, Мияконодзё, Нобеока, Нитинан, Кобаяси, Хюга, Сайто, Кусима, Эбино)
• Отдельные записи старого блога (больше 100: от колонок про конкретные районы до практических статей о переезде для одного человека и о дальнем переезде)
• Файлы, которые не являются страницами, но отдаются публично: robots.txt, sitemap.xml, файл подтверждения владения в Search Console, старый скрипт отправки формы (php/submit.php)

Колонок в таблице инвентаризации достаточно таких. Если повторяете приём, начните с них.

Только когда эта таблица готова, можно строить таблицу соответствий (маппинг URL): для каждого адреса решить, что с ним делать на новом сайте. В таблице соответствий хватает трёх колонок. Держите старый URL, решение и куда ведёт; обоснование оставьте в примечании таблицы инвентаризации — тогда таблицу соответствий можно механически превратить в определения редиректов.

В этом проекте решения в таблице соответствий свели к двум видам.

Постоянные страницы, региональные страницы и действующие осмысленные URL записей блога — все keep (без изменений). URL со случайной строкой, которую система пронумеровала сама (вроде /blog/5lmln1lx0x/), и адреса вроде post20210721.html мы решили перенаправлять по 301 на новые URL статей с понятным slug.

Отдельно в ту же таблицу попал php/submit.php — скрипт-приёмник, который остался на старом сайте. На него не ссылалась ни одна форма в опубликованном HTML, а реально работали только три канала: телефон, почта и расчёт в LINE. Мы сочли его заброшенным обработчиком и поставили 301 на /contact/ (как к этому пришли, подробнее в главе 6).

При проектировании редиректов жёстко держали два правила.

• Завершать за один переход (не строить цепочку редиректов)
• На этапе сборки проверять, что URL назначения существует (чтобы 301 не увёл на несуществующий адрес)

Если инвентаризацию и таблицу соответствий закрепить до разговора о дизайне, реализация и тексты идут уже по основе «что лежит по какому URL», и переделок меньше. Это не специфика данного проекта: так стоит начинать любое обновление старого сайта, у которого уже есть обратные ссылки или поисковый трафик.

3. Как мы реализовали 301-редиректы

Таблица соответствий сама по себе ничего не делает, пока её не превратят в реальные ответы 301. Именно эту часть статьи чаще всего опускают — и именно она больше всего мешает повторить приём. Поэтому пишем конкретно.

Новый сайт — генерация статики плюс Cloudflare Pages. В такой схеме редиректы задают в двух местах.

Если это разделение не понять сразу, получается типичная трата времени: «в _redirects написали строку для www, а она не работает». _redirects действует на пути внутри сайта и не умеет ветвить запросы по имени хоста.

3.1 Пути внутри того же хоста — файл _redirects

У Cloudflare Pages есть механизм: если в корень результата сборки положить текстовый файл с именем _redirects, сервис отдаёт редиректы по его содержимому. Формат простой: в одной строке через пробел «исходный путь», «куда», «код статуса».

/blog/5lmln1lx0x/          /blog/oneroom-mansion-hikkoshi/   301
/blog/post20210721.html    /blog/oneroom-mansion-hikkoshi/   301
/php/submit.php            /contact/                         301

Код 301 в конце строки нужно указывать явно. Если его опустить, запрос обработают как 302 (временное перемещение), и это уже не постоянный переезд, с которого вы хотите перенести поисковый вес. Лимит статических редиректов — 2 000 записей; если масштаб больше, их нужно уводить в Bulk Redirects.

Мы _redirects не писали руками: его генерирует скрипт сборки из таблицы соответствий. Определения редиректов лежат в скрипте сборки массивом, и при выводе файл пишется построчно. По смыслу это выглядит так.

// Таблица соответствий (старый URL → новый URL) лежит в одном месте
const redirects = [
  ["/blog/5lmln1lx0x/", "/blog/oneroom-mansion-hikkoshi/"],
  ["/blog/post20210721.html", "/blog/oneroom-mansion-hikkoshi/"],
  ["/php/submit.php", "/contact/"],
];

// В dist/_redirects пишем строки вида «исходный путь назначение 301»
const body = redirects.map(([from, to]) => `${from} ${to} 301`).join("\n");
await fs.writeFile("dist/_redirects", `${body}\n`);

У этого два плюса. Первый: правила из главы 2 — «один переход» и «назначение существует» — можно проверить автотестами на этапе сборки. Мы сделали тест, который сверяет число и содержимое сгенерированного _redirects с ожидаемым и подтверждает, что все записи — одношаговые 301. Второй: если URL статьи меняется, правите таблицу соответствий, и _redirects подхватывает изменение сам — нельзя починить только одну сторону и сломать связку.

3.2 Смена имени хоста — Redirect Rules в Cloudflare

Редирект с www.douzucarry.com на apex (douzucarry.com) и любые другие случаи, где меняется имя хоста, задают в панели Cloudflare. Порядок такой.

1. В нужной зоне убедиться, что DNS-запись www есть и прокси включён (Proxied). Без DNS-записи запрос до Cloudflare вообще не дойдёт.
2. Открыть Rules > Redirect Rules > Create rule.
3. В условии (When) указать «Hostname equals www.douzucarry.com».
4. В действии (Then) выбрать Dynamic redirect, выражение назначения — concat("https://douzucarry.com", http.request.uri.path). Статус 301, Preserve query string — ON.

Путь в выражении оставляем как есть, потому что каждую страницу на www нужно один к одному отправить на тот же путь на apex. Если же, как в главе 7 со старым доменом лендинга, содержимое сведено на одну страницу нового сайта, путь как раз переносить нельзя. Если к назначению дописывать фрагмент, захваченный wildcard, получится 301 на несуществующий адрес вроде /refrigerated/foo: вырастет число 404, и вес не соберётся в одной точке. В таком случае назначение — один фиксированный URL.

3.3 Почему не берём остальные варианты

Если старый сайт работал на PHP или Apache, можно написать в .htaccess правило RewriteRule ... [R=301,L]. Это разумно, когда старую среду ещё какое-то время оставляют. Перенаправление через HTML <meta http-equiv="refresh"> как HTTP-статус остаётся 200, поэтому его не стоит выбирать там, где нужен именно 301. То же с подменой location.href в JavaScript. Чтобы поисковая система поняла «мы переехали», 301 должен отдать сервер.

4. Чек-лист, чтобы контент не «выпал»

Параллельно с URL мы составили чек-лист сохранности контента: вся информация, которая была на старом сайте, должна без пробелов появиться и на новом.

При обновлении в процессе смены дизайна мелкие формулировки и цифры нередко пропадают сами собой. Если выпадут цены, часы работы, контакты, сильные стороны — то, по чему человек решает обратиться, — сайт выглядит лучше, а обращений становится меньше.

Поэтому для каждой основной страницы мы выписали обязательные сведения со старого сайта. Часть списка такая.

С этим списком перед запуском мы сверили старые и новые страницы одну за другой и проверили, что ничего не выпало. Смысл приёма в том, что «материал для решения» — цены, часы, сильные стороны — перенесён как есть, несмотря на новый дизайн, и это держит список, а не память.

5. Локальное SEO — девять региональных страниц

Среди страниц, которые перешли со старого сайта, есть отдельные страницы по девяти территориям: Миядзаки, Мияконодзё, Нобеока, Нитинан, Кобаяси, Хюга, Сайто, Кусима и Эбино.

Эти страницы — посадочные под запросы с названием места: «[город] + переезд», «[город] + доставка». У перевозок и переездов рынок привязан к территории, и такие страницы закрывают спрос, который главная и страница цен сами не соберут.

В таблице соответствий все девять адресов от /area/miyazaki/ до /area/ebino/ стоят как keep (URL не меняем); сама эта схема при обновлении не трогалась. Рядом много записей блога, привязанных к каждому региону: конкретные районы внутри города Миядзаки, внутри Мияконодзё и так далее. Региональные страницы и блог дополняют друг друга.

Страницы одного шаблона, где меняется только название города, при тонком тексте выглядят и для поисковой системы, и для читателя как копирование одной и той же страницы. Здесь разделение ролей уже было на старом сайте: сама региональная страница держит уровень города, а блог отдельно описывает районы внутри. Типичной «тонкости» шаблонных страниц эта схема уже избегала. При обновлении мы её не ломали и URL оставили как есть.

6. Свести разрозненные каналы обращений

Как мы обошлись с php/submit.php из главы 2, важно и для пути к обращению.

Разобрав старый сайт, мы убедились, что из опубликованных каналов реально работали только три.

• Телефон (0120-931-677, приём 8:00–20:00)
• Почта
• Расчёт в LINE

Сам скрипт-приёмник php/submit.php в коде оставался, но ни одна форма в опубликованном HTML на него не ссылалась. Это был заброшенный скрипт, которым уже не пользовались. Поэтому на новом сайте телефон, почту и расчёт в LINE мы собрали на /contact/, а запросы к php/submit.php отправляем туда же по 301.

Когда каналы размазаны по страницам и скриптам, в момент обновления легко потерять, чем люди на самом деле пользуются. Сначала выяснить, какие каналы живые, и только потом сводить их — тот же принцип, что и при пересмотре пути главная → услуга → контакты. Об этом же шла речь в более ранней статье «Три места, которые стоит исправить в первую очередь, если с сайта нет обращений».

7. Навести порядок со старыми доменами — заброшенный домен лендинга

У транспортных компаний, которые под каждую услугу делали отдельный лендинг, домены со временем расползаются, часто незаметно. И здесь тоже пришлось разбирать такой набор.

Незакрытым остался только третий пункт. Разницу мы увидели в проверке перед запуском из главы 8: не «казалось, что настроили», а что 301 реально возвращается.

Третий случай — главный урок. Содержание старого лендинга рефрижераторной доставки (машины с установкой до −20 °C, круглосуточно 365 дней, регулярные рейсы и маршрутная доставка) уже лежит на /refrigerated/. Но сам старый домен, судя по всему, с истекшим DNS и не резолвится, поэтому 301 с него поставить нельзя. Если домен не продлевать и не обслуживать, вес обратных ссылок и трафик по запросам с названием компании можно потерять внезапно.

Если у компании лендинги услуг живут на отдельных доменах и вы думаете об обновлении, мало решить, куда свести контент. Одновременно проверьте договор по старому домену: продлевается ли он и жив ли DNS. От того, успеете ли поставить 301, пока восстановление ещё возможно, зависит, насколько легко потом перенести накопленный вес.

8. Что проверить до запуска и что делать после

Перед запуском нового сайта мы проверили следующее.

• Сверку с чек-листом сохранности контента из главы 4 (на старых и новых страницах одни и те же элементы)
• Фактическую проверку 301 (отправить запросы и убедиться, что приходят ожидаемые код и назначение)
• Что файл подтверждения владения в Search Console отдаёт 200
• Что файлы, нужные для публикации, действительно отдаются: robots.txt, sitemap.xml, _headers (_headers — файл именно Cloudflare Pages: как и _redirects, его кладут в корень результата сборки, и по путям можно добавить заголовки ответа. Здесь же задают заголовки безопасности и управление кэшем)

301 проверяйте командой, не браузером. Браузер сам идёт по редиректам: если посередине вклинился 302, вы всё равно увидите конечную страницу и не заметите проблему. curl -I (только заголовки, редиректы не сопровождает) показывает код статуса и заголовок Location как есть.

# URL старого блога с ID уходит 301 на новый URL со slug
curl -I https://douzucarry.com/blog/5lmln1lx0x/

# То же для .html с датой в имени файла
curl -I https://douzucarry.com/blog/post20210721.html

# Запрос на www уходит 301 на apex (и путь сохраняется)
curl -I https://www.douzucarry.com/price/

Смотреть нужно две вещи: в первой строке статус 301 и значение Location: совпадает с колонкой «куда ведёт» в таблице соответствий. Если пришёл 302 — в _redirects забыли код статуса; если Location сам ведёт ещё куда-то — уже цепочка. Все строки redirect из таблицы соответствий проверяют так, по одной.

После запуска тоже есть работа.

• Заново отправить sitemap.xml в Search Console
• Инструментом проверки URL по отдельности убедиться, что ID-URL старого блога и .html с датой в имени файла отдают ожидаемый 301
• Несколько недель смотреть в отчёте об индексировании (Coverage), начали ли старые URL, которые раньше были 404 или вне индекса, распознаваться как «Redirect»

Обновление сайта не заканчивается публикацией. Имеет смысл закладывать в план, что работа завершена только когда поисковая система после запуска действительно распознала редиректы.

9. Итог — общие правила, чтобы обновление не сломалось

Из кейса Douzu Carry Service можно вынести подходы, которые годятся и для других обновлений.

• Сначала URL, дизайн потом. Если у старого сайта уже есть поисковый трафик или обратные ссылки, до разговора о внешнем виде зафиксируйте полную инвентаризацию URL и таблицу соответствий с новыми адресами (301-маппинг).
• Не запускать без инвентаризации контента. Цены, часы работы, контакты, сильные стороны — «материал для решения» — сверяют чек-листом, страница за страницей, и только потом публикуют.
• Оставлять только живые каналы. Нашли неиспользуемую форму или скрипт отправки — сначала проверьте, чем пользуются на деле, затем сведите на живой канал.
• Один переход и проверка, что назначение существует. Не строить цепочки и иметь механизм, который не отправит на несуществующий URL.
• 301 задают в двух местах. Пути внутри того же хоста — файл в результате сборки (для Cloudflare Pages это _redirects); смена имени хоста — правила на стороне CDN и DNS. В обоих случаях код статуса указывают явно и перед запуском проверяют каждую запись через curl -I.
• Домены разбирать, пока они ещё живы. Брошенный отдельный домен лендинга услуги после истечения DNS может стать невосстановимым — и тогда переносить вес уже некуда.

Обновление сайта — это не только новый дизайн. Это ещё и проектирование: как перенести накопленный поисковый вес и путь к обращению. Краткий обзор этого кейса — в материале «Организация сайта Douzu Carry Service».

Если похожие сомнения есть по URL или по переносу существующего контента, инвентаризацию старого сайта можно пройти вместе в рамках консультации по разработке сайтов.

Похожие статьи

• Организация сайта Douzu Carry Service
• Почему KomuraSoft делает сайты на дизайн-системе Цифрового агентства Японии — дешевизна и качество совместимы
• Три места, которые стоит исправить в первую очередь, если с сайта нет обращений
• Разработка сайтов
• Контакты

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

С чего начинать обновление сайта?

Не с макета дизайна, а с таблицы инвентаризации, где перечислены все URL старого сайта. Нужно без пропусков выписать постоянные страницы, региональные страницы и записи блога, а также файлы, которые не являются страницами, но отдаются публично: robots.txt, файл подтверждения владения в Search Console, скрипт отправки формы. Затем для каждого URL составляют таблицу соответствий: keep (не менять) или redirect (301-редирект). Если эту основу зафиксировать раньше, на реализации и создании контента будет меньше переделок.

Как спроектировать редиректы, чтобы при обновлении не потерять позиции в поиске?

Значимые URL — постоянные страницы, региональные страницы и подобные — оставляют как есть (keep). По 301 перенаправляют только бессмысленные адреса, которые система пронумеровала сама, на новые URL с понятным slug. Два правила, которые нужно соблюдать жёстко: каждый редирект завершается за один переход, без цепочки; на этапе сборки проверяют, что URL назначения существует, чтобы 301 не увёл на несуществующий адрес. После запуска несколько недель смотрят Search Console, пока редиректы не будут распознаны.

Почему после обновления сайта иногда падает число обращений?

Потому что, пока обновляют дизайн, из страниц незаметно пропадают данные, по которым человек решает написать: цены, часы работы, контакты, сильные стороны. Чтобы этого не случилось, для каждой основной страницы составляют чек-лист сохранности контента — обязательные сведения со старого сайта (тарифы, часы приёма, перечень услуг) — и перед запуском сверяют старую и новую страницу одну за другой. Держать это списком, а не памятью и на глаз, и есть суть приёма.

Можно ли не трогать неиспользуемый лендинг на отдельном домене?

Оставлять его без присмотра опасно. В этом кейсе старый домен лендинга рефрижераторной доставки перестал резолвиться — скорее всего, истёк DNS, — и хотя контент уже перенесли на новый сайт, 301 со старого домена настроить было нельзя. Если домен не продлевать и не обслуживать, накопленный вес обратных ссылок и трафик по запросам с названием компании можно потерять в один день. Когда планируете обновление, одновременно проверьте договор по старому домену и то, жив ли DNS, и поставьте 301, пока восстановление ещё возможно.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.