Рецепт карти редиректів: ранжування старих URL за кількістю посилань, що на них ведуть
Карта редиректів — це пріоритетний список, а не таблиця з усіма URL. Починайте зі сторінок, на які посилаються інші сайти, і решта карти буде сформуватися простіше.
Команда досліджень ArchiLinks ·
Чому ранжувати за посиланнями
Команди часто будують карти на основі краулингу. Це повно, але такий підхід ставиться до забутої прес-сторінки 2014 року так само, як і до головної.
Коли ви перевіряєте беклінки до свого сайту та сортуєте сторінки за кількістю посилальних доменів, у більшості міграцій простежується закономірність: кілька десятків URL зосереджують більшість зовнішнього посилального капіталу. Саме ці URL підлягають ручному зіставленню, подвійній перевірці та першочерговому тестуванню.
Усе інше підпорядковується правилам. Теки мапуються за шаблоном, параметри відсікаються, а URL-посилання без посилань і без трафіку можуть повертати 410, якщо ви так вирішите. Поєднуйте результат із чек-листом міграції, щоб карта пройшла тестування до запуску та повторну перевірку на 45-й день, а також із скриптами API для налаштування щомісячного отримання даних.
Крок 1: отримання сторінок із посиланнями
Один запит повертає до 1000 рядків і коштує 2 кредити, незалежно від фактичної кількості рядків. Назви полів нижче наведені як приклад; подивіться на реальну відповідь та адаптуйте ключі.
import csv, requests
BASE = "https://archilinks.com/api.php"
KEY = "sk_live_..."
def call(action, **params):
r = requests.get(BASE, params={"action": action, "key": KEY, **params}, timeout=30)
r.raise_for_status()
return r.json()
data = call("toppages", q="old-shop.com", per=1000)
rows = next(v for v in data.values() if isinstance(v, list))
with open("linked-pages.csv", "w", newline="") as f:
w = csv.writer(f)
w.writerow(["old_url", "links", "new_url"])
for row in rows:
w.writerow([row.get("url"), row.get("backlinks"), ""])Крок 2: заповнення третього стовпця
Зіставлення за змістом
Сторінка товару має перенаправляти на той самий товар або на його категорію, якщо товар знято з виробництва. Ніколи не на головну, якщо це не була головна сторінка.
Нехай друга особа перевірить топ-50
Втомлена людина о 18:00 може помилково зіставити гайд з канонічних URL із індексом блогу. Перевірювач це помітить.
Правила для «довгого хвоста»
Напишіть шаблони для тек та відсікайте трекингові параметри. Зберігайте кожне правило в системі контролю версій із коментарем, що пояснює, чому воно було додано.
Крок 3: генерація правил сервера
nginx добре працює з файлами map, і він масштабується на десятки тисяч рядків.
# /etc/nginx/redirects.map (generated from the csv)
/old/guide-canonicals /guides/canonical-tags;
/products/blue-widget /shop/widgets/blue;
# in nginx.conf, http context
map $request_uri $new_uri {
default "";
include /etc/nginx/redirects.map;
}
# in the server block of the old host
if ($new_uri) {
return 301 https://new-shop.com$new_uri;
}
Крок 4: тестування кожного переходу
Зупиняйте конвеєр, якщо результат не є одиночним 301 на 200.
while IFS=, read -r old new; do
out=$(curl -s -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}" -L "https://old-shop.com$old")
echo "$old -> $out"
done < redirect-pairs.csv | grep -v "^.* -> 200 1 " && echo "FIX ABOVE"Помилки, на які ми б звернули увагу в першу чергу
| Симптом | Ймовірна причина | Виправлення |
|---|---|---|
| Цепочки з двох або трьох переходів | Старі правила, накладені на нові | Направте старе правило прямо на фінальний URL |
| Усе потрапляє на головну сторінку | Ліниве правило catch-all | Зіставляйте за темою; Google може сприймати масові редиректи на головну як м'які 404 |
| Втрачаються рядки запиту | Правило відсікає аргументи | Зберігайте параметри, що змінюють контент; відсікайте решту |
| Топовий URL повертає 404 після запуску | Винесено з CSV | Повторно запустіть отримання даних та зробіть diff із живою картою |
Які URL заслуговують на ручне зіставлення
Не кожен URL заслуговує на увагу людини. Корисний поділ — за посилальними доменами: будь-який URL, на який посилається кілька зовнішніх сайтів, підлягає ручному зіставленню, а решта йде за набором правил. Скажімо, у вас є 4000 старих URL, і 60 з них зосереджують більшість зовнішніх посилань. Ці шістдесят потребують попівденної перевірки, тоді як інші 3940 обробляються за шаблоном і тестом.
Тримайте поріг у скрипті, а не в голові у виконавця. П'ять посилальних доменів — розумний старт для середнього сайту. Почніть із цього. Зменшуйте число, якщо на всьому сайті мало посилань, і збільшуйте, якщо список ручної обробки стає занадто довгим для одного перевіряча.
Збереження окремістості рядків із ручним та шаблонним зіставленням
Рядки з ручним зіставленням отримують іменованого перевіряча та нотатку, чому обрано ціль. Рядки з шаблонним зіставленням отримують шаблон, протестований на всю теку, тому виняток покаже звіт тестування до запуску, а не графік трафіку після нього.
Змішані випадки викликають більшу плутанину. Товар, який знято з виробництва і замінено наступником, перенаправляє на наступника. Один знятий без наступника належить до своєї категорії, ніколи до головної.
Використання другого запиту для відстеження змін
Запустіть refdomains для старого хоста перед фіналізацією карти, потім знову після запуску, і зіставте два списки за доменом. Посилальний домен, відсутній у другому запиті, — це питання до власника посилання, а не привід для тривоги, оскільки видалене посилання може довго відображатися в індексі.
Зберігайте обидва файли поруч у теці міграції, вказуючи дату в назвах кожного. Diff покаже, куди дивитися, а карта — що ви з цим зробили.
Вирішення долі URL без посилань
URL-посилання без посилань і без трафіку — це легка частина. Повертайте чіткий 404 або 410, якщо контент зник назавжди, і робіть редирект лише тоді, коли існує близька заміна, щоб відвідувачі та краулери потрапляли кудись корисне.
Коли ви сумніваєтеся, залиште коротку нотатку в карті та поверніться після першого тижня логів. Логи сервера покажуть, які старі адреси все ще отримують запити, що є найкращим доказом, який у вас буде.
Як карта вписується в процес випуску
Карта редиректів змінюється разом із сайтом. Майте це на увазі. З'являються нові сторінки, старі перейменовуються, а зміна шаблону може зламати правило, яке виглядало безпечним минулого місяця. Ставтеся до карти як до коду: один файл у системі контролю версій, рецензія перед кожним деплоєм та тестовий запуск на кожну зміну.
Намагайтеся тримати карту в одному шарі. Редиректи, розкидані по додатку, CDN та CMS, — це те, звідки беруться ланцюжки, а ланцюжки важко виявити без повного краулингу.
Де мають жити правила
Серверна карта працює швидко і легко тестується. Плагін CMS зручний для кількох сторінок, але його важко аудитувати в масштабі. Який би ви вибір не зробили, тест на один перехід має читати з того ж місця.
Якщо два шари перенаправляють той самий URL, тест повідомить про ланцюжок. Видаліть дублікат із того шару, який плануєте вивести з експлуатації.
Тестування на реальному хості після кожної зміни
Запускайте тест переходів на staging, а потім на production після кожної зміни файлу правил. Правило, яке пройшло на staging, все ще може не спрацювати, якщо кеш тримає стару відповідь, тому другий запуск має значення.
Зберігайте результат із датою. Коли топ-URL зламається через кілька місяців, старий результат покаже, чи змінилося правило, чи сам сайт. Чек-лист міграції вказує, коли цей тест має виконуватися, а запуск його першим робить наступну перевірку порівнянною з цією.
Перегляд зміни файлу правил
Призначте одного перевіряча для змін у карті і попросіть цю особу перевірити три речі: чи відповідає кожна ціль темі, скільки переходів створює правило, чи достатньо вузький шаблон, щоб торкатися лише URL, для яких він написаний. Зміна, яку ніхто не рецензував, — це та, яка найімовірніше запустить ланцюжок.
Просіть той самий рецензій, коли змінюється сам сайт. Нова категорія, що поглинула стару теку, може змусити правильне правило вказувати не туди, без редагування карти кимось.
Зберігайте нотатку перевіряча поруч із зміною. Через пів року нотатка пояснить правило, яке інакше виглядало б довільно, і заощадить друге розслідування того ж питання.
Тестування вибірки перед повним запуском
Перш ніж запустити весь список, виберіть вибірку з п'ятдесяти рядків, що містить як топ-сторінки з посиланнями, так і кілька звичайних. Спочатку запустіть тест переходів на цій вибірці. Вибірка швидко читається, а помилка правила проявиться в ній задовго до того, як вона проявиться в повному файлі.
Включіть принаймні один рядок із кожного шаблону правил та один із кожної групи ручного зіставлення. Шаблон, що покриває теку з двохсот URL, тестується лише рядками, які випадково потрапили у вибірку, тому обирайте їх свідомо.
Збереження файлів правил невеликого розміру
Файл правил, що виріс понад кілька сотень шаблонів, стає важким для рецензування. Розділіть його за розділами сайту та тримайте кожен файл коротким, щоб перевіряч міг прочитати його за один присід.
Видаляйте правило того дня, коли зникає його тека. Старі правила, що залишилися, — це ті, що пізніше відправлять трафік у ланцюжок.
Перед тим, як карта піде в продакшн
- Кожен рядок має новий URL або свідомий 404/410.
- Жодна ціль не є сам редиректом.
- 50 URL із найбільшою кількістю посилальних доменів були перевірені другою особою.
- Параметри запиту, що змінюють контент, зберігаються.
- Файл правил у системі контролю версій із коментарем до кожного шаблону.
- Базовий показник посилальних доменів збережено для post-launch diff.
Питання щодо редиректів, що постійно виникають
- Чи варто видаляти старі редиректи після року?
- Багато команд міграції зберігають їх принаймні рік. Після цього тримайте їх доти, доки старі URL все ще отримують зовнішні посилання або трафік. Редиректи коштують майже нічого в обслуговуванні, тому рідко є хороша причина видаляти їх достроково.
- Чи можна перенаправляти лише індексовані сторінки?
- Ні, якщо неіндексовані несуть посилання. Статус індексації мало говорить про зовнішню цінність. Перенаправляйте кожен URL, що має посилальний домен, а решту вирішуйте за трафіком.
- Щодо 302 або 307 для постійного переміщення?
- Використовуйте 301 або 308 для постійних переміщень. 302, залишений на роки, може бути сприйнятий як постійний, але цей результат залишається на волю випадку, а інші клієнти редиректу можуть тлумачити інакше.
- Чи можна перенаправляти 404 зі старого сайту на новий?
- Лише коли існує близька відповідність. Редирект на неспоріднену сторінку в очах Google — це м'який 404. Повертайте справжній 404 або 410, якщо контент зник.
