Миграция на уебсайт без загуба на SEO: redirect map, canonical и QA

SEO миграцията не започва в деня на launch. Тя започва, когато inventory-ваме старите URL-и и решим кои нови страници реално наследяват техния intent, links и историческа стойност.

Първата задача е URL inventory

Съберете всички известни URL-и от текущия сайт, не само тези в sitemap. Полезни източници са XML sitemap, CMS export, analytics landing pages, Search Console, backlink tools, server logs и crawl на текущия сайт.

За всеки URL отбелязваме поне:

• текущ status code;
• indexability и canonical;
• page type и основен intent;
• organic clicks/impressions, когато данните са налични;
• backlinks или външни mentions;
• нов еквивалент;
• решение: keep, 301, merge, 404/410.

Не сменяйте URL само защото дизайнът е нов

Редизайнът не е причина да променяме адрес, който вече е логичен, кратък и натрупва сигнали. Ако старата `/uslugi/seo-optimizatsiya/` остава основната страница за SEO услугата, най-сигурното решение е да запазим URL-а и да сменим съдържанието и дизайна зад него.

Това намалява redirect зависимостта и риска от временна загуба на сигнали. Именно по тази логика се проектира и SEO архитектурата преди дизайн.

Кога 301 е правилният избор

Permanent redirect има смисъл, когато старата страница има ясен нов наследник със същото или много близко потребителско намерение. Пример: стара отделна страница за Instagram Ads може да се консолидира към нова Meta Ads страница, ако тя реално покрива Facebook и Instagram и отговаря на очакването на потребителя.

Кога да не използвате 301

Ако услугата е премахната и няма реален заместител, redirect към homepage или произволна услуга е лош user experience и може да се интерпретира като soft 404. В такъв случай честен 404 или 410 често е по-доброто решение.

Избягвайте redirect chains

Ако A вече redirect-ва към B, а при новия redesign B трябва да стане C, актуализирайте A → C директно. Chains увеличават crawl overhead, забавят потребителя и усложняват бъдещия maintenance.

Internal links трябва да сочат към финалния URL

301 е safety net за стари сигнали и външни входове, не вътрешна навигационна стратегия. След migration crawl-нете сайта и заменете всички internal links, които минават през redirect.

Проверете header, mega menu, footer, breadcrumbs, related services, blog content, CTA блокове, sitemap и structured data references.

Canonical и robots QA

Всеки важен нов landing page трябва да има self-referencing canonical, освен ако има умишлена consolidation логика. Проверете дали staging noindex не е останал в production и дали robots.txt не блокира важни assets или директории.

• 200 canonical page → canonical към себе си;
• 301 URL → няма нужда от indexable page markup;
• 404/410 → noindex е приемлив допълнителен сигнал, но status code е основният;
• sitemap → само canonical, indexable, 200 URLs.

Schema и breadcrumbs също са част от migration

Ако URL hierarchy или page type се променя, обновете BreadcrumbList, Service/Product/Article relationships и всички hardcoded @id references. Structured data не трябва да продължава да сочи към retired URL.

Tracking трябва да преживее redesign-а

Промяна на form markup, button classes или checkout може да счупи selector-based tracking. Преди launch направете inventory на GA4/GTM events и ги валидирайте на новите templates. Когато е възможно, предпочитайте dataLayer events пред крехки CSS selectors.

Pre-launch crawl

1. Crawl-нете staging с финалната URL структура.
2. Сравнете URL inventory с redirect map.
3. Проверете всички вътрешни links за 3xx/4xx.
4. Проверете title, H1, canonical, robots и structured data.
5. Проверете sitemap само с final URLs.
6. Тествайте mobile и performance на ключовите templates.
7. Валидирайте analytics и conversion events.

Post-launch monitoring

След launch следете server/analytics/Search Console сигнали за 404, redirect issues, indexing changes и спадове по важни landing pages. Не променяйте redirect map хаотично всеки ден — първо потвърдете причината.

За техническата страна вижте Technical SEO, а за самата услуга — миграция на уебсайт.

Добрата SEO миграция не се опитва да запази всеки стар URL на всяка цена. Тя запазва правилните сигнали и прави новата архитектура по-ясна от старата.