SEO-редиректи: 301 vs 302 і перевірка міграції

Семантика статусів

301 vs 302 — це рішення про постійність; 307 vs 308 додає семантику HTTP-методу

Обирайте код із реального стану ресурсу, а не з міфу про «SEO-вагу» статусу.

Корисніше думати про SEO redirects не як про питання «який код передає більше ваги», а як про твердження сервера щодо URL. Google зараз трактує 301 і 308 як постійні перенаправлення, а 302, 303 і 307 — як тимчасові. Для постійного переміщення Google рекомендує серверний постійний редирект, коли це технічно можливо. Для справді тимчасового маршруту потрібна тимчасова семантика, щоб вихідний URL міг залишатися довгостроковою пошуковою адресою.

ДжерелоGoogle Search Central — Redirects and Google Search

Семантика HTTP-редиректів для SEO та запитів
Статус	Стан ресурсу	Поведінка методу	Типовий сценарій
301 Moved Permanently	Постійна нова URI	RFC 9110 дозволяє окремим клієнтам змінити POST на GET	Постійна зміна сторінки, шляху або домену
302 Found	Тимчасова інша URI	RFC 9110 дозволяє окремим клієнтам змінити POST на GET	Тимчасовий збій або маршрут, де вихідна сторінка має лишитися основною
307 Temporary Redirect	Тимчасова інша URI	Метод має зберігатися	Тимчасове перенаправлення для запитів зі станом і non-GET
308 Permanent Redirect	Постійна нова URI	Метод має зберігатися	Постійне переміщення, де важливе збереження методу

ДжерелоGoogle Search Central — Redirects and Google Search · RFC Editor — RFC 9110: HTTP Semantics — Redirection 3xx

Кастомна схема

Спочатку визначте постійність переміщення, потім — семантику HTTP-методу

Дерево рішень розділяє постійні й тимчасові переміщення, а далі відрізняє 301/302 від 308/307, коли для non-GET запитів критичне збереження методу.

Для звичайних цільових SEO-сторінок із GET-запитами перше питання — постійність. Збереження методу стає важливим, якщо той самий маршрут обробляє POST або інші запити зі станом.

Якщо запит сформульовано як what is 301 redirect in SEO, точна відповідь така: HTTP 301 повідомляє, що ресурс постійно переміщений, і передає нову адресу в Location. Пошукові системи можуть використовувати це як сигнал канонікалізації. Варіанти 301 redirects SEO та seo 301 redirect описують ту саму технічну задачу: постійність плюс релевантність кінцевої адреси.

ДжерелоGoogle Search Central — Redirects and Google Search · RFC Editor — RFC 9110: HTTP Semantics — Redirection 3xx

Модель станів URL

Вирішіть, чи старий URL має редиректитися, залишатися доступним із canonical або повертати 404/410

Редирект виводить URL з експлуатації. Canonical залишає дублікат доступним. 404/410 означає, що заміни немає.

Типова помилка міграції виникає ще до написання правила: команда не визначила, що має означати старий URL після запуску. Google називає постійні редиректи та rel=canonical сильними сигналами канонікалізації, а наявність у sitemap — слабшим сигналом. Але вони описують різні стани продукту. Якщо дубль має залишатися доступним, canonical може вказати пріоритет без видалення URL. Якщо контент виводиться з експлуатації й має реального наступника — редирект. Якщо рівнозначної заміни немає — чесний 404 або 410 кращий за нерелевантне перенаправлення на категорію чи головну.

ДжерелоGoogle Search Central — How to Specify a Canonical with rel=canonical and Other Methods · Google Search Central — What is URL Canonicalization · Google Search Central — Site Moves and Migrations

Рішення за станом URL: redirect, canonical або видалення
Стан старого URL	Контроль	Навіщо	Перевірка релізу
Є постійний еквівалент	301 або 308 → кінцева адреса	Вивести стару адресу й указати нову canonical location	Ціль релевантна, доступна для індексації й повертає очікуваний 200
Є тимчасова альтернативна адреса	302 або 307	Зберегти вихідний ресурс як довгостроковий	Тимчасовий стан має відповідального та умову відкату
Дубль має лишитися доступним	200 + rel=canonical	Вказати пріоритет без видалення дубля	Canonical-ціль еквівалентна, сигнали не суперечать
Контент видалено без заміни	404 або 410	Не вигадувати релевантність нерелевантним редиректом	Внутрішні посилання й sitemap більше не рекламують URL

ДжерелоGoogle Search Central — Redirects and Google Search · Google Search Central — Site Moves and Migrations · Google Search Central — How to Specify a Canonical with rel=canonical and Other Methods

Контракт міграції

Побудуйте мапінг старий→новий URL на основі даних ще до написання правил

Мапа міграції — це перевірюваний набір рішень. Regex — лише техніка реалізації, а не джерело істини.

Надійна SEO migration strategy починається з інвентаризації, а не з універсального правила з wildcard. Поточна документація Google радить формувати мапінг URL до запуску редиректів і шукати важливі старі URL у sitemap, серверних логах або аналітиці, даних про посилання Search Console та CMS; за потреби до плану міграції входять і технічні ресурси. Експорти беклінків можуть додати рівень пріоритизації: старий URL із цінними зовнішніми посиланнями потребує явної перевірки, навіть якщо його вже немає в навігації.

ДжерелоGoogle Search Central — Site Moves and Migrations

Побудуйте мапінг, який можуть однаково перевірити SEO та розробник

1
Зберіть старі URL з кількох джерел
Об'єднайте інвентар URL зі сканування, XML sitemap, серверні логи/аналітику, URL із Search Console, експорти CMS і важливі URL з беклінками. Збережіть походження даних, щоб пояснювати походження кожного URL.
КритерійКожен важливий старий URL має стабільний source_url і поле, що показує джерело його виявлення.
ДжерелоGoogle Search Central — Site Moves and Migrations
2
Класифікуйте стан URL до вибору цілі
Позначте рядок як постійне переміщення, тимчасове переміщення, доступний дублікат, консолідацію або видалення без заміни. Не визначайте стан лише за схожістю рядків URL.
КритерійКожен вихідний URL має один погоджений стан і зрозуміле пояснення.
3
Мапте на найближчий еквівалент
Ціль має виконувати ту саму або свідомо консолідовану задачу користувача. Мапінг «багато до одного» допустимий для реального об'єднання контенту, але масове перенаправлення на нерелевантну головну сторінку може виглядати як soft 404.
КритерійКожна ціль редиректу має пояснювану відповідність або документовану причину консолідації.
ДжерелоGoogle Search Central — Site Moves and Migrations
4
Відокремте контракт мапінгу від генератора серверних правил
За можливості генеруйте правила Apache, NGINX, edge-рівня або застосунку із погодженого мапінгу. Так карту можна перевірити до реалізації, а регулярний вираз не перетворюється на приховану бізнес-логіку.
КритерійРецензент бачить джерело, ціль, статус і причину без читання серверну конфігурацію.

Практичний website migration checklist SEO має містити окремий критерій приймання мапінгу: без дубльованих source_url, саморедиректів, цілей, які самі заплановані як джерело редиректу, порожніх target для постійного переміщення та неперевірених масових консолідацій. Далі в статті є відтворюваний скрипт для цих перевірок.

Кастомна схема

Серверні правила мають бути результатом погодженого мапінгу станів URL

Джерела даних формують інвентар старих URL, кожен рядок отримує визначений стан і кінцеву ціль, після чого з погодженої мапи генеруються та перевіряються правила.

Так рішення про релевантність відділяється від синтаксису реалізації. Regex може бути ефективним, але не повинен сам вирішувати, які сторінки еквівалентні.

Цілісність маршруту

Ланцюжки й цикли редиректів — зазвичай дефект мапінгу, а не абстрактна проблема «бюджету сканування»

Googlebot здатен пройти довгий ланцюг, але контрольована міграція зазвичай має вести старий URL одразу на кінцеву адресу.

Google пише, що Googlebot може пройти до 10 переходів, але в рекомендаціях для міграцій радить вести одразу на кінцеву адресу, а коли ланцюга не уникнути — тримати його коротким: в ідеалі не більше трьох і менше п'яти. Це не ціль для дизайну. Для контрольованих міграцій наш критерій релізу — один перехід редиректу: старий URL → кінцевий URL зі статусом 200. Кожен додатковий перехід додає затримку й ще одну точку, де може з'явитися тимчасовий статус, цикл або мертва ціль.

ДжерелоGoogle Search Central — Site Moves and Migrations

Перевіряйте ланцюжки редиректів і зі списку старих URL, і з актуального графа внутрішніх посилань

1
Перевірте список старих URL у List Mode
У Screaming Frog SEO Spider завантажте список запланованих/старих URL і ввімкніть Always Follow Redirects, щоб простежити кожне джерело до кінцевої відповіді.
ШляхMode → List; Configuration → Spider → Advanced → Always Follow Redirects
КритерійКожне джерело доходить до очікуваного кінцевого статусу й цілі; тимчасові переходи та цикли видно.
ДжерелоScreaming Frog — How To Audit Redirects In A Site Migration Using The SEO Spider
2
Проскануйте актуальний сайт на внутрішні посилання через 3xx
Редирект може бути правильним для старого зовнішнього URL, але непотрібним у поточній навігації. Перейдіть до Response Codes → Redirection (3XX), а потім Inlinks, щоб знайти сторінки, які ще посилаються на стару адресу.
ШляхResponse Codes → Redirection (3XX) → Inlinks
КритерійПоточні внутрішні посилання ведуть прямо на кінцеві canonical URL, крім документованих винятків.
ДжерелоScreaming Frog — Check Redirects In Bulk
3
Виносьте ланцюжки й цикли в дефекти релізу
Використайте звіт Redirect Chains для внутрішніх ланцюжків і циклів, а міграційний звіт All Redirects — для перевірки від вихідного до кінцевого URL. Призначайте дефект власнику правила чи джерела посилання, а не просто рахуйте переходи.
ШляхReports → Redirects → Redirect Chains
КритерійЖодне контрольоване джерело не залежить від іншого запланованого редиректу, і жодного циклу не лишилося.
ДжерелоScreaming Frog — Check Redirects In Bulk · Screaming Frog — How To Audit Redirects In A Site Migration Using The SEO Spider

Узгодження сигналів

Redirect, canonical, внутрішні посилання, sitemap і hreflang мають збігатися на одному кінцевому URL

Канонікалізацію складніше діагностувати, коли кожна система називає інший бажаний URL.

Головний урок canonical tags SEO під час міграції — не «додати більше canonical», а прибрати суперечності. Google називає редиректи і rel=canonical сильними сигналами, а наявність у sitemap — слабшим і зазначає, що ці методи можуть підсилювати один одного. Також рекомендовано self-canonical на canonical-сторінці і послідовні внутрішні посилання саме на canonical URL. Тому нова сторінка не повинна отримувати redirect зі старої, коли її canonical, sitemap, hreflang або основні внутрішні посилання і далі вказують назад.

ДжерелоGoogle Search Central — How to Specify a Canonical with rel=canonical and Other Methods · Google Search Central — Site Moves and Migrations

Кастомна схема

Міграцію легше інтерпретувати, коли всі сигнали називають один кінцевий URL

Старий URL постійно редиректиться на кінцевий URL зі статусом 200; кінцева сторінка має self-canonical, а sitemap, hreflang та внутрішні посилання також посилаються на цю адресу.

Canonical-декларації — це підказки, а не абсолютні команди. Узгодження сигналів зменшує неоднозначність замість спроби «пересилити» суперечливу реалізацію.

Перевірка узгодженості canonical-сигналів після зміни URL
Рівень	Очікуваний стан	Типовий дефект	Власник
Redirect	Старий URL → кінцевий новий URL	Старий → проміжний → кінцевий; неправильна локаль/категорія	Маршрутизація/платформа
rel=canonical	Кінцевий URL має self-canonical	Canonical кінцевої сторінки вказує назад на старий URL або інший варіант	Шаблон/SEO
Внутрішні посилання	Посилання прямо на кінцевий canonical URL	Посилання в навігації/контенті і далі проходять через 3xx	Frontend/контент
XML sitemap	Містить кінцеві canonical URL	Старі URL із редиректом залишилися серед поточних canonical	SEO/платформа
hreflang	Використовує нові взаємні URL	Старі URL або URL із редиректом лишилися в мовному кластері	Міжнародне SEO/платформа

ДжерелоGoogle Search Central — Site Moves and Migrations · Google Search Central — How to Specify a Canonical with rel=canonical and Other Methods

Google може вибрати інший canonical, якщо бачить сильніші або суперечливі сигнали; canonical, заданий сайтом, не є абсолютною командою. Тому перевірка міграції має охоплювати весь набір сигналів. Чекліст технічного SEO-аудиту перевіряє цю узгодженість на рівні загального аудиту; тут вона стає контрактом релізу конкретної міграції.

ДжерелоGoogle Search Central — What is URL Canonicalization

Критерій релізу

Перевірте мапу редиректів як граф ще до першого бойового запиту

Статична попередня перевірка знаходить дублікати джерел, заплановані ланцюжки, цикли й некоректні стани видалення до розгортання серверної конфігурації.

Ручний перегляд таблиці потрібен, але погано знаходить дефекти графа у тисячах рядків. Невеликий скрипт нижче трактує мапінг як структуровані дані. Він свідомо підтримує рядки постійної міграції (301/308) і явні видалення (404/410). Тимчасові 302/307 краще вести в окремому операційному списку з відповідальним та умовою відкату, а не непомітно змішувати з мапою постійної міграції.

VERIFIED · Preflight redirect_map.csv as a graph, not a list

#!/usr/bin/env python3
"""Validate a planned redirect_map.csv before release.

Required columns:
source_url,target_url,expected_status,reason

For 301/308 rows target_url is required.
For 404/410 rows target_url must be empty.
This is a static mapping check: it does not request live URLs.
"""

import csv
import sys
from pathlib import Path
from urllib.parse import urlparse

REDIRECT_STATUSES = {301, 308}
DELETION_STATUSES = {404, 410}
ALLOWED_STATUSES = REDIRECT_STATUSES | DELETION_STATUSES
REQUIRED_COLUMNS = {"source_url", "target_url", "expected_status", "reason"}


def absolute_http_url(value: str) -> bool:
    parsed = urlparse(value)
    return parsed.scheme in {"http", "https"} and bool(parsed.netloc)


def load_rows(path: Path):
    with path.open(newline="", encoding="utf-8-sig") as handle:
        reader = csv.DictReader(handle)
        missing = REQUIRED_COLUMNS - set(reader.fieldnames or [])
        if missing:
            raise ValueError(f"Missing columns: {', '.join(sorted(missing))}")
        return [{k: (v or "").strip() for k, v in row.items()} for row in reader]


def validate(rows):
    errors = []
    warnings = []
    by_source = {}

    for number, row in enumerate(rows, start=2):
        source = row["source_url"]
        target = row["target_url"]
        reason = row["reason"]
        try:
            status = int(row["expected_status"])
        except ValueError:
            errors.append(f"row {number}: expected_status must be an integer")
            continue

        if not absolute_http_url(source):
            errors.append(f"row {number}: invalid source_url {source!r}")
        if source in by_source:
            errors.append(f"row {number}: duplicate source_url {source}")
        by_source[source] = {**row, "status": status, "row": number}

        if status not in ALLOWED_STATUSES:
            errors.append(f"row {number}: status {status} is outside the release contract")
        if not reason:
            errors.append(f"row {number}: reason is required for reviewability")

        if status in REDIRECT_STATUSES:
            if not absolute_http_url(target):
                errors.append(f"row {number}: 301/308 requires an absolute target_url")
            if source == target:
                errors.append(f"row {number}: self-redirect {source}")
        elif status in DELETION_STATUSES and target:
            errors.append(f"row {number}: 404/410 row must not have target_url")

    # The planned map should point directly to final destinations.
    # If a target is also a redirect source, the release would create a chain.
    for source, row in by_source.items():
        if row["status"] not in REDIRECT_STATUSES:
            continue
        target = row["target_url"]
        if target in by_source and by_source[target]["status"] in REDIRECT_STATUSES:
            errors.append(f"planned chain: {source} -> {target} -> {by_source[target]['target_url']}")

    # Independent cycle detection produces a clearer error for A -> B -> A.
    for source in by_source:
        seen = []
        current = source
        while current in by_source and by_source[current]["status"] in REDIRECT_STATUSES:
            if current in seen:
                cycle = seen[seen.index(current):] + [current]
                errors.append("redirect cycle: " + " -> ".join(cycle))
                break
            seen.append(current)
            current = by_source[current]["target_url"]

    # Many-to-one is valid for real consolidation, but it deserves review.
    targets = {}
    for source, row in by_source.items():
        if row["status"] in REDIRECT_STATUSES:
            targets.setdefault(row["target_url"], []).append(source)
    for target, source_list in targets.items():
        if len(source_list) >= 3:
            warnings.append(f"review consolidation: {len(source_list)} sources -> {target}")

    return sorted(set(errors)), sorted(set(warnings))


def main():
    path = Path(sys.argv[1] if len(sys.argv) > 1 else "redirect_map.csv")
    rows = load_rows(path)
    errors, warnings = validate(rows)
    for warning in warnings:
        print("WARN:", warning)
    if errors:
        for error in errors:
            print("ERROR:", error)
        print(f"FAIL: {len(errors)} release-blocking mapping issue(s)")
        raise SystemExit(1)
    print(f"PASS: {len(rows)} mapping row(s); no planned chains, cycles or schema violations")


if __name__ == "__main__":
    main()

Виконано Python 3 2026-09-04 на synthetic valid і навмисно broken fixtures. Скрипт перевіряє структуру mapping; він не робить network requests і не доводить, що live targets повертають 200.

ДжерелоGoogle Search Central — Site Moves and Migrations

Зробіть скрипт блокувальною передрелізною перевіркою

1
Експортуйте погоджений redirect_map.csv
Використайте чотири обов'язкові колонки: source_url, target_url, expected_status, reason. Зберігайте пояснення відповідності контенту у самій карті, щоб рецензент міг оскаржити сумнівний мапінг «багато до одного».
КритерійCSV зберігається у версійному контролі разом із релізом міграції, кожен рядок має пояснення.
2
Запустіть скрипт до генерації серверних правил
Виконайте python validate_redirect_map.py redirect_map.csv. FAIL блокує реліз; WARN про консолідацію потребує перегляду, а не автоматичного відхилення.
Шляхpython validate_redirect_map.py redirect_map.csv
КритерійСкрипт завершується з exit 0 та PASS без помилок запланованих ланцюжків, циклів або схеми.
3
Після цього перевірте згенеровані редиректи на тестовому або бойовому endpoint
Статична перевірка мапінгу не доводить HTTP-поведінку. Після деплою правил перевірте статус, заголовок Location, кількість переходів і кінцеву відповідь через краулер, URL Inspection для репрезентативних URL для Google або інструменти командного рядка.
КритерійФактичні HTTP-шляхи збігаються з погодженим мапінгом, а кінцеві сторінки відповідають контракту індексованості/canonical.
ДжерелоGoogle Search Central — Site Moves and Migrations · Screaming Frog — How To Audit Redirects In A Site Migration Using The SEO Spider

Для Apache офіційна документація показує постійні серверні редиректи через Redirect permanent або R=301 rewrite, де це доречно; NGINX return підтримує 301/302/303/307/308, а rewrite ... permanent повертає 301. Генеруйте конфігурацію під реальну топологію сервера, а не копіюйте загальне правило без урахування проксі, маршрутизації локалей чи стану застосунку.

ДжерелоApache HTTP Server Project — Redirecting and Remapping with mod_rewrite · NGINX — Module ngx_http_rewrite_module

Фактичні спостереження

Після запуску перевіряйте окремо: чи працює редирект, чи кінцевий URL є canonical і чи Google обробляє міграцію

Коректність HTTP, стан canonical/індексації та перебіг міграції — це різні питання з різними джерелами даних і часовими рамками.

Кастомна схема

Перевірка міграції — цикл від мапінгу до фактичних даних сканування й Search

Погоджений мапінг розгортається, перевіряється HTTP-скануванням і логами, потім — Search Console та даними трафіку; аномалії повертаються до відповідної карти або правила шаблону.

Не використовуйте зміни позицій/трафіку як перший доказ технічної коректності. Спочатку перевірте HTTP-шлях і кінцевий canonical-стан, потім спостерігайте за обробкою міграції з часом.

У Search Console важливо розрізняти стани. Page with redirect означає неканонічний URL, який перенаправляє на іншу сторінку й тому сам не індексується; для застарілого URL це може бути очікуваним станом, який не потрібно «валідувати до нуля». Redirect error — інша категорія: Google перелічує надто довгий ланцюжок, цикл, URL, що перевищив максимальну довжину, або пошкоджений або порожній URL у ланцюжку. Перевірка в реальному часі через URL Inspection проходить редиректи й тестує кінцевий URL, хоча не показує всі переходи.

ДжерелоGoogle Search Console Help — Page indexing report

Виконуйте перевірки після запуску у причинному порядку

1
Підтвердьте HTTP-поведінку на списку URL міграції
Повторно проскануйте збережений список старих URL і порівняйте фактичний початковий статус, кількість переходів, кінцеву адресу та кінцевий статус із погодженою мапою до інтерпретації Search Console або змін трафіку.
КритерійРепрезентативні та важливі старі URL напряму доходять до запланованої кінцевої адреси з потрібним постійним статусом.
ДжерелоScreaming Frog — How To Audit Redirects In A Site Migration Using The SEO Spider
2
Перевірте сигнали кінцевої сторінки
Проскануйте новий сайт на self-canonical, індексованість, внутрішні посилання, sitemap і hreflang. Для важливих кінцевих URL використайте URL Inspection, коли потрібні дані про canonical, вибраний Google.
КритерійКінцева сторінка — саме та версія, яку сайт послідовно рекламує як canonical; неочікуваний вибір canonical стає окремою діагностикою.
ДжерелоGoogle Search Central — Site Moves and Migrations · Google Search Central — What is URL Canonicalization
3
Моніторте старі/нові ресурси й когорти в часі
Відстежуйте логи краулера й помилки, дані індексації й Search performance у Search Console, аналітику та обробку нового sitemap. Google зазначає, що значні міграції можуть коливатися під час повторного сканування й переіндексації і займати тижні або більше залежно від розміру сайту й потужності сервера.
КритерійАктивність старих URL знижується, виявлення/індексація/пошукова активність нових URL зростає, а неочікувані когорти 4xx/5xx/Redirect error мають відповідальних.
ДжерелоGoogle Search Central — Site Moves and Migrations
4
Використовуйте Change of Address лише для підтримуваних типів переміщення
Google вказує цей інструмент для перенесень домену/субдомену. Він не потрібен для HTTP→HTTPS, www↔non-www на тому самому домені або змін шляхів всередині домену.
КритерійІнструкція міграції використовує Change of Address лише для перенесень домену/субдомену.
ДжерелоGoogle Search Central — Site Moves and Migrations

Постійна політика

Міграція завершена, коли трафік старих URL безпечно переходить на нові, а не коли минув день запуску

Збереження редиректів, очищення внутрішніх посилань і моніторингу потребують власників і після релізу.

Google радить тримати редиректи міграції якомога довше, загалом щонайменше рік, щоб сигнали зі старих URL могли бути повторно проскановані й перепризначені; для користувачів варто розглянути ще довше збереження. Але це не означає нескінченно зберігати технічний борг внутрішніх редиректів. Оновіть внутрішні посилання та важливі зовнішні, профільні й рекламні адреси на нові URL, щоб звичайний трафік не залежав від шару сумісності.

ДжерелоGoogle Search Central — Site Moves and Migrations

Операційна політика міграції після запуску
Контроль	Питання відповідального	Нормальний стан	Ескалація
Інвентаризація редиректів	Чи всі застарілі URL і далі покриті?	Відомі старі URL працюють за погодженою картою	З'явився новий 404/когорта помилок редиректів
Внутрішні посилання	Чи поточний сайт досі залежить від redirects?	Навігація/шаблони/контент посилаються на кінцеві URL	3xx inlinks зростають після релізів
Canonical/sitemap/hreflang	Чи узгоджені поточні сигнали?	Усі поточні сигнали виявлення називають кінцеві canonical URL	Старі/альтернативні URL повертаються в поточних сигналах
Logs/Search Console	Чи обробляється міграція нормально?	Сканування переходить на нові URL без неочікуваних помилок	Старі цінні URL перестають скануватися без доступної для виявлення цільової сторінки
Термін зберігання	Чи можна безпечно прибрати правило?	Вік + трафік/беклінки/потребу користувачів перевірено перед виведенням URL з експлуатації	Правило видалено лише тому, що «минув рік»

ДжерелоGoogle Search Central — Site Moves and Migrations · Google Search Console Help — Page indexing report

Для зміни CMS або платформи діють ті самі принципи, навіть якщо домен не змінюється. CMS migration SEO план має зберігати ідентичність URL там, де це можливо; коли змінюються шляхи, карта редиректів, canonical-шаблони, генерація sitemap і компоненти внутрішніх посилань стають єдиною поверхнею релізу. Якщо після HTTP-перевірки лишається незрозумілий стан індексації, гайд про Crawled — Currently Not Indexed корисніший за нескінченне переписування правил редиректів.

Першоджерела та документація

Джерела

Кожне змінне твердження про пошукову систему, браузер, інтерфейс або технічну поведінку в матеріалі прив’язане до актуального першоджерела.

Google Search Central Redirects and Google Search (відкриється в новій вкладці)Первинне джерело для інтерпретації постійних і тимчасових редиректів, серверних перенаправлень, 301/302/307/308 та обмежень JavaScript fallback.
Google Search Central Site Moves and Migrations (відкриється в новій вкладці)Первинне джерело щодо мапінгу URL, редиректів під час перенесення сайту, ланцюжків, Change of Address, моніторингу міграції та терміну збереження редиректів.
Google Search Central How to Specify a Canonical with rel=canonical and Other Methods (відкриється в новій вкладці)Первинне джерело щодо сили сигналів redirect/canonical/sitemap, self-canonical та узгоджених внутрішніх посилань.
Google Search Central What is URL Canonicalization (відкриється в новій вкладці)Первинне джерело про те, як Google обирає репрезентативні URL і чому canonical-декларації залишаються підказками, а не абсолютними командами.
Google Search Console Help Page indexing report (відкриється в новій вкладці)Первинне джерело щодо станів Page with redirect, Redirect error та поведінки URL Inspection.
RFC Editor RFC 9110: HTTP Semantics — Redirection 3xx (відкриється в новій вкладці)Семантика HTTP для 301, 302, 307 і 308, зокрема відмінності щодо збереження методу запиту.
Screaming Frog Check Redirects In Bulk (відкриється в новій вкладці)Поточний процес у SEO Spider для пошуку 3xx-відповідей, вхідних посилань через редиректи, ланцюжків і циклів.
Screaming Frog How To Audit Redirects In A Site Migration Using The SEO Spider (відкриється в новій вкладці)Поточний процес міграційної перевірки в режимі List та поля звіту All Redirects для початкового/кінцевого URL, переходів, циклів, тимчасових редиректів і кінцевого статусу.
Apache HTTP Server Project Redirecting and Remapping with mod_rewrite (відкриється в новій вкладці)Офіційні приклади Apache для постійних серверних редиректів і переходу HTTPS/canonical host.
NGINX Module ngx_http_rewrite_module (відкриється в новій вкладці)Офіційна семантика NGINX для директив return/rewrite та відповідей 301/302/303/307/308.

Потрібна допомога з діагностикою та впровадженням?

Перетворіть список редиректів на контракт релізу міграції

Metricum Lab може змоделювати стани застарілих URL, спроєктувати правила редиректів і canonical, перевірити шляхи міграції до запуску та моніторити дані сканування й індексації після релізу з явними критеріями приймання.

Переглянути послуги з Technical SEO

SEO-редиректи: 301 vs 302, ланцюжки, canonical та перевірка міграції

Постійне переміщення

Тимчасове переміщення

Ціль для міграції

Збереження редиректів

301 vs 302 — це рішення про постійність; 307 vs 308 додає семантику HTTP-методу

Спочатку визначте постійність переміщення, потім — семантику HTTP-методу

Вирішіть, чи старий URL має редиректитися, залишатися доступним із canonical або повертати 404/410

Побудуйте мапінг старий→новий URL на основі даних ще до написання правил

Побудуйте мапінг, який можуть однаково перевірити SEO та розробник

Зберіть старі URL з кількох джерел

Класифікуйте стан URL до вибору цілі

Мапте на найближчий еквівалент

Відокремте контракт мапінгу від генератора серверних правил

Серверні правила мають бути результатом погодженого мапінгу станів URL

Ланцюжки й цикли редиректів — зазвичай дефект мапінгу, а не абстрактна проблема «бюджету сканування»

Перевіряйте ланцюжки редиректів і зі списку старих URL, і з актуального графа внутрішніх посилань

Перевірте список старих URL у List Mode

Проскануйте актуальний сайт на внутрішні посилання через 3xx

Виносьте ланцюжки й цикли в дефекти релізу

Redirect, canonical, внутрішні посилання, sitemap і hreflang мають збігатися на одному кінцевому URL

Міграцію легше інтерпретувати, коли всі сигнали називають один кінцевий URL

Перевірте мапу редиректів як граф ще до першого бойового запиту

VERIFIED · Preflight redirect_map.csv as a graph, not a list

Зробіть скрипт блокувальною передрелізною перевіркою

Експортуйте погоджений redirect_map.csv

Запустіть скрипт до генерації серверних правил

Після цього перевірте згенеровані редиректи на тестовому або бойовому endpoint

Після запуску перевіряйте окремо: чи працює редирект, чи кінцевий URL є canonical і чи Google обробляє міграцію

Перевірка міграції — цикл від мапінгу до фактичних даних сканування й Search

Виконуйте перевірки після запуску у причинному порядку

Підтвердьте HTTP-поведінку на списку URL міграції

Перевірте сигнали кінцевої сторінки

Моніторте старі/нові ресурси й когорти в часі

Використовуйте Change of Address лише для підтримуваних типів переміщення

Міграція завершена, коли трафік старих URL безпечно переходить на нові, а не коли минув день запуску

Джерела

Перетворіть список редиректів на контракт релізу міграції