Переезд с shared-хостинга на GitHub Pages: как перенести сайт на Hugo, не сломав ни одной ссылки и не вылетев из индекса Google и Яндекса

Это продолжение статьи про автоматизацию публикации ProHomeLab (Obsidian → Forgejo → Hugo). Если ты еще не настроил этот пайплайн - сначала прочитай ту статью, здесь я буду опираться на нее как на готовую базу.

Если у тебя уже работает автоматическая публикация через Forgejo Actions, следующий логичный шаг - задуматься о том, где у тебя сайт хостится. Я держал ProHomeLab на shared-хостинге¹, но решил переехать на GitHub Pages. Тому было несколько причин, но это бесплатно, надежно и снимает с меня заботу о сервере как таковом. При этом были определенные проблемы с доступом к сайту из зарубежа.

Проблема в том, что «просто взять и переехать» - плохая идея для сайта, который уже проиндексирован. Один неверный шаг со сменой DNS или переносом домена приведет к потере позиций в Google и Яндексе на несколько недель, пока поисковики заново разбираются, что случилось с сайтом. В этой статье я подробно, шаг за шагом, покажу, как перенести хостинг сайта так, чтобы для читателей и поисковиков ничего не изменилось. Если не учитывать, что сайт теперь резолвится с серверов GitHub.

Что у нас есть на старте

#

• Домен prohomelab.com, DNS уже переведен на Cloudflare, режим - DNS only (серое облако, без проксирования Cloudflare). Это важная деталь. Если бы прокси Cloudflare был включен, GitHub не смог бы провалидировать домен и выпустить сертификат.
• Рабочий пайплайн следующий. Пишешь статью в Obsidian → Obsidian Git коммитит и пушит в Forgejo (prohomelab-content) → срабатывает workflow_dispatch → на самосборном раннере (LXC-контейнер в Proxmox, Hugo с темой Blowfish) выполняется hugo -D → готовый public/ заливается по FTP на старый хостинг.
• Мы меняем только последний шаг - вместо заливки по FTP собранный сайт будет пушиться в репозиторий на GitHub, откуда его раздает GitHub Pages. Все остальное - Obsidian, Forgejo, раннер, сборка Hugo - остается как есть.

Почему я решил делать именно так, а не сразу «по уму» (сборка через GitHub Actions, Forgejo - просто зеркало)? Потому что это бы означало самостоятельную и более крупную перестройку архитектуры. Решил, что делать ее одновременно с переездом на новый хостинг лишний риск. Сначала стабилизируем работу сайта на новом хостинге, все проверим, потом, без спешки, упростим сборку.

Почему это не может сломать SEO

#

Самое важное в этой схеме - мы не меняем домен и не меняем структуру URL. Для Google и Яндекса это не «переезд сайта» в том смысле, в котором они боятся редиректов, потери ссылочной массы и просадки трафика на недели. С точки зрения поисковика сайт prohomelab.com как отдавал одни и те же адреса статей, так и будет отдавать - просто теперь запрос до сервера идет до серверов GitHub вместо старого хостинга. Это невидимо для краулера, если мы где-то не напортачим. А это очень легко, например:

1. Поменять структуру ссылок. Если permalinks в Hugo вдруг станут другими (например, добавится или пропадет слэш, изменится формат /posts/slug/ на /slug/) - старые проиндексированные страницы превратятся в 404, и вот тогда действительно начнутся проблемы.
2. Оставить сайт без HTTPS на долгое время или с «битым» сертификатом. Google понижает в выдаче сайты с проблемами безопасности, а браузеры пугают пользователей.
3. Долгий простой во время переключения DNS. Если сайт «лежит» сутки - это не катастрофа, но лучше свести окно недоступности к минимуму.
4. Молча потерять верификацию Google Search Console / Яндекс.Вебмастер. Об этом ниже - отдельный важный пункт, который легко упустить именно потому, что он никак не связан напрямую с GitHub.

Дальше - конкретные шаги, которые все это учитывают.

Шаг 1. Создай репозиторий на GitHub

#

Зайди на GitHub и создай новый публичный репозиторий - например, prohomelab-pages. Публичный он должен быть потому, что бесплатный GitHub Pages на личном аккаунте раздает сайты именно из публичных репозиториев (либо нужен приватный репозиторий и специальный workflow с actions/deploy-pages, но это уже про следующие шаги с GitHub Actions, не сейчас).

Название репозитория не обязано совпадать с твой-юзер.github.io - раз у нас будет свой домен, это ограничение не действует.

Шаг 2. Проверь, что Hugo не поменяет структуру ссылок

#

Это самый критичный для SEO шаг во всей статье, поэтому не пропускай его.

Открой конфиг Hugo (hugo.toml или config.yaml в корне проекта Blowfish) и найди там:

• baseURL - должен остаться https://prohomelab.com/, без изменений;
• permalinks (если задан для секции posts) - должен быть точно таким же, каким собирался сайт для старого хостинга;
• uglyURLs - должен остаться в том же положении (false, скорее всего, раз у тебя адреса вида /posts/slug/, а не /posts/slug.html).

Раз мы используем тот же самый Hugo-проект, что и раньше, и просто меняем точку деплоя - по умолчанию тут ничего не должно измениться. Но проверять все нужно руками, потому что если это единственное, что пойдет не так, то именно это ударит по позициям в поиске больнее всего.

Шаг 3. Создай токен для пуша из Forgejo в GitHub

#

Forgejo Actions должен уметь пушить в твой новый репозиторий на GitHub - для этого нужен токен.

1. На GitHub: Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token.
2. Repository access - выбери Only select repositories и укажи только что созданный prohomelab-pages.
3. Permissions → Repository permissions → Contents: Read and write. Больше никаких прав не давай - токен должен уметь ровно то, что нужно, не более того.
4. Сгенерируй токен и сразу скопируй его - второй раз GitHub его не покажет.

Дальше идем в Forgejo, в репозиторий prohomelab-site → Settings → Actions → Secrets и добавь новый секрет, например GH_PAGES_TOKEN, вставляем данные токена.

Шаг 4. Добавляем файл CNAME, чтобы домен не терялся при каждой сборке

#

GitHub Pages узнает, какой у сайта кастомный домен, по файлу CNAME в корне репозитория. Если мы будем каждый раз пушить свежую сборку public/ целиком (перезаписывая репозиторий), этот файл нужно генерировать вместе с остальным сайтом - иначе он будет теряться после первого же деплоя.

Создай в проекте Hugo (там, где Blowfish) файл static/CNAME с единственной строкой:

prohomelab.com

Hugo автоматически копирует все из static/ в public/ при каждой сборке, так что файл будет попадать в деплой сам, без дополнительных действий.

Шаг 5. Поменяй последний шаг в deploy.yml

#

Открой deploy.yml в репозитории prohomelab-site в Forgejo. Найди шаг, который заливает public/ по FTP на старый хостинг, и замени его на пуш в GitHub. Логика шага:

  - name: Deploy to GitHub Pages
    run: |
      cd public
      git init
      git checkout -b main
      git add -A
      git -c user.name="prohomelab-bot" -c user.email="bot@prohomelab.com" commit -m "Deploy: ${{ gitea.sha }}"
      git push --force https://x-access-token:${{ secrets.GH_PAGES_TOKEN }}@github.com/твой-юзер/prohomelab-pages.git main

Замени твой-юзер на свой логин GitHub. Шаги Sync content и Build with Hugo перед этим шагом не трогаешь - они как работали, так и работают, меняется только пункт назначения готовой сборки.

Сохрани, закоммить изменения в prohomelab-site. Пока не запускай - сначала нужно включить Pages на стороне GitHub (следующий шаг), иначе пушить будет некуда для проверки результата.

Шаг 6. Включи GitHub Pages и проверь сборку БЕЗ переключения домена

#

Это ключевой момент для безопасного переезда. Мы полностью проверяем, что сайт корректно собирается и работает на GitHub, до того, как меняем настройки DNS. Так у нас в любой момент есть возможность моментально откатиться на старый хостинг, если что-то пошло не так.

1. В репозитории prohomelab-pages → Settings → Pages.
2. Source: Deploy from a branch.
3. Branch: main, папка / (root).
4. Custom domain пока не трогаем - оставь пустым.
5. Сохрани.

Теперь вручную запусти workflow deploy.yml в Forgejo (через кнопку в интерфейсе или через workflow_dispatch API, которым ты уже пользуешься). Через минуту-другую после первого пуша GitHub соберет Pages, и сайт станет доступен по адресу вида:

https://твой-юзер.github.io/prohomelab-pages/

Переходим по этому адресу. Проверяем пару статей и убеждаемся, что картинки, стили и внутренние ссылки на месте. Не пугаемся, если что-то будет выглядеть немного не так, как ожидаешь (например, из-за baseURL, «зашитого» на prohomelab.com, некоторые абсолютные ссылки могут вести не туда) - это ожидаемо на этом промежуточном адресе и не значит, что после переключения домена будет так же. Главное на этом шаге убедиться, что сама сборка происходит без ошибок и контент на месте.

Шаг 7. Проверяем, что верификация в Search Console и Яндекс.Вебмастере на месте

#

Это тот самый пункт, который часто упускают, потому что он формально не связан с GitHub. Однако он связан с тем, что домен недавно переехал на Cloudflare.

Верификация сайта в Google Search Console и Яндекс.Вебмастере чаще всего делается одним из способов:

• через TXT-запись в DNS домена (самый частый и самый «хрупкий» при переезде DNS способ);
• через мета-тег на главной странице;
• через файл на сервере.

Если верификация у тебя была через TXT-запись в DNS, а ты недавно переносил DNS-зону на Cloudflare - эта запись не переехала вместе с остальными. Проверяем:

1. Зайди в Cloudflare → DNS → Records для prohomelab.com и поищи TXT-записи вида google-site-verification=... или похожие для Яндекса.
2. Если их нет - зайди в Google Search Console и Яндекс.Вебмастер, посмотри статус верификации сайта. Если он «слетел» - просто добавь актуальную TXT-запись заново в Cloudflare (сервисы покажут тебе точное значение в интерфейсе верификации).

Сделать это стоит до переключения на GitHub, а не после - чтобы к моменту, когда начнется реальный мониторинг после окончательного переезда, доступ к данным в обеих панелях точно работал.

Заодно проверяем robots.txt (https://prohomelab.com/robots.txt) - что там нет случайного Disallow: /, и sitemap.xml (https://prohomelab.com/sitemap.xml) - Hugo генерирует его автоматически, он должен собираться и на GitHub Pages точно так же, как собирался на старом хостинге.

Шаг 8. Переключение: DNS и домен

#

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

1. В GitHub, в Settings → Pages репозитория prohomelab-pages, впиши Custom domain: prohomelab.com. GitHub попробует сразу проверить DNS и, скорее всего, покажет ошибку - это нормально, DNS еще не переключен.

2. Сразу после этого - в Cloudflare, в DNS-записях prohomelab.com, замени текущие A-записи (которые указывают на старый хостинг) на четыре A-записи, указывающие на GitHub Pages:

   Тип	Имя	Значение
   A	@	185.199.108.153
   A	@	185.199.109.153
   A	@	185.199.110.153
   A	@	185.199.111.153

   Режим оставь DNS only (серое облако) - не включай проксирование Cloudflare, пока GitHub не выпустит сертификат (следующий шаг).

   Если используешь поддомен www - добавь CNAME www → твой-юзер.github.io.

   Можно указать еще и AAAA-записи, но я, по-моему, их не делал.

3. DNS обновляется не мгновенно - обычно от нескольких минут до часа, иногда дольше. Проверить распространение записей можно на любом удобном тебе сервисе, например whatsmydns.net (если РКН не заблокировал к нему доступ) по домену prohomelab.com, тип записи A.

Шаг 9. Дождись сертификата и включи HTTPS

#

Как только GitHub увидит, что домен резолвится на его IP-адреса, он автоматически запросит сертификат Let’s Encrypt. Обычно это занимает от нескольких минут до пары часов, но дольше 1 минуты у меня никогда не было. Пока сертификат не выпущен, сайт может быть доступен только по HTTP или показывать предупреждение браузера о небезопасном соединении - не паникуем, это ожидаемое временное состояние, не поломка.

Как только в Settings → Pages появится чекбокс Enforce HTTPS - включи его. С этого момента весь трафик на http:// будет автоматически редиректиться на https://, что важно и для пользователей, и для поисковиков (Google явно учитывает HTTPS как фактор ранжирования).

Шаг 10. Финальная проверка перед отключением старого хостинга

#

Не спешим выключать старый хостинг. Сначала:

1. Открываем https://prohomelab.com в приватном окне браузера (чтобы точно не увидеть закешированную старую версию) и, если есть возможность, еще и с другого DNS-резолвера (например, временно переключи DNS на устройстве на 1.1.1.1) - чтобы убедиться, что видишь именно новую версию, а не старый хостинг по старому кешу.
2. В заголовках ответа сервера должно быть что-то вроде server: GitHub.com - это можно проверить через вкладку Network в инструментах разработчика браузера.
3. Пройдемся по 10–15 старым URL статей (особенно тем, что хорошо ранжируются или приводят трафик) и убедись, что ни один не отдает 404.
4. Проверяем sitemap.xml и robots.txt еще раз - уже на «боевом» домене.
5. В Google Search Console и Яндекс.Вебмастере вручную отправь sitemap заново (даже если адрес не изменился). Это не обязательно, но может немного ускорить повторный обход изменившегося IP поисковыми роботами.

Только после того, как все это подтверждено и проработало стабильно хотя бы пару дней - можно отключать (ну или не продлевать) хостинг у твоего хостера.

Что дальше мониторить

#

В первые одну-две недели после переезда полезно периодически заглядывать в:

• Google Search Console → Индексирование → Страницы - не появилось ли резкого роста ошибок 404 или «Страница не найдена»;
• Яндекс.Вебмастер → Индексирование → Диагностика сайта - то же самое для Яндекса;
• аналитику посещаемости (если она у тебя настроена) - на предмет резких провалов трафика с органического поиска.

Небольшие и кратковременные колебания позиций после смены IP/сервера - это нормально, поисковики иногда пересчитывают технические метрики (скорость ответа, доступность). Насторожиться стоит, только если через пару недель ты видишь устойчивое падение или массовые 404 - тогда возвращайся к шагам 2 и 7 этой статьи и перепроверяй их еще раз.

Чек-лист

#

• Репозиторий на GitHub создан, публичный
• baseURL, permalinks, uglyURLs в Hugo не менялись
• Fine-grained токен создан и добавлен как secret в Forgejo
• static/CNAME с prohomelab.com добавлен в проект
• Шаг деплоя в deploy.yml заменен с FTP на git push в GitHub
• Сборка проверена на твой-юзер.github.io/repo/ до переключения DNS
• TXT-записи верификации Google Search Console / Яндекс.Вебмастер на месте в Cloudflare
• robots.txt и sitemap.xml проверены
• A-записи в Cloudflare переключены на GitHub Pages, режим DNS only
• Custom domain добавлен в настройках GitHub Pages
• Сертификат выпущен, Enforce HTTPS включен
• Старые URL статей проверены на 404 на боевом домене
• Sitemap повторно отправлен в Search Console и Яндекс.Вебмастере
• Через 1–2 недели индексирование стабильно, только после этого старый хостинг отключен

В следующей статье серии разберу второй этап. Перенос самой сборки на GitHub Actions и превращение Forgejo в резервную копию сайта.