Накратко: Позициите се губят не от новия дизайн, а от изгубените адреси. Преди старта запишете текущите адреси, трафика и запитванията по страница, а после направете карта на пренасочванията едно към едно с постоянно пренасочване от сървъра. Google съветва да пазите пренасочванията поне една година и изрично предупреждава да не пращате много стари адреси към началната страница на новия сайт.
Редизайнът е добър повод да оправите структурата, скоростта и текстовете. Той е и типичният момент, в който сайт губи голяма част от трафика си за една нощ. Разликата между двата изхода е в подготовката, а не в платформата. Правилата по-долу са от документацията на Google Search Central, с датата на всяка страница. Сроковете за проверка след пускането отбелязваме като наша препоръка.
Какво да запишете, преди да започне работата?
Първата стъпка не е дизайн, а снимка на сегашното състояние. Ако нямате тази снимка, после няма как да докажете какво е спаднало и заради коя страница.
- Пълен списък с адресите: Google съветва да започнете от важните адреси в sitemap файловете, в логовете на сървъра и в анализите, а системата за управление на съдържанието да даде пълния списък.
- Кликове и показвания по страница: от Search Console, за последните 12 месеца, за да видите и сезонността.
- Запитвания и поръчки по страница: от GA4 и от собствената Ви система. Страницата, която води класацията по посещения, рядко води и по запитвания.
- Сайтове, които препращат към Вас: Google съветва да запазите списъка и да помолите тези сайтове да обновят връзките към новите адреси.
- Вграденото съдържание: изображения, видео, PDF файлове, CSS и JavaScript също имат адреси и също се местят.
- Заглавия и подзаглавия: заглавната връзка в резултатите се съставя автоматично, но Google посочва съдържанието на елемента title като първи източник за нея.
| Какво записвате | Откъде | За какво служи |
|---|---|---|
| Списък с адресите | sitemap, CMS, логове на сървъра | основа на картата на пренасочванията |
| Кликове и показвания по страница | Search Console | коя страница носи видимост |
| Запитвания и поръчки по страница | GA4 и Вашата система | коя страница носи приход |
| Сайтове, които препращат | Search Console | кого да помолите да обнови връзката |
| Заглавия и подзаглавия | обхождане на сайта | какво да не се загуби при пренаписване |
| Вградени файлове | обхождане на сайта | изображенията и PDF файловете също имат адреси |
Кога да запазите адресите и кога да ги смените?
Правилото е кратко: не сменяйте адрес, за който нямате причина. Всяка смяна изисква пренасочване, а всяко пренасочване е място, на което нещо може да се счупи.
Основателни причини за смяна са малко: преминаване към друг домейн, преминаване към HTTPS, обединяване на две страници с почти еднакво съдържание и структура, която вече не отговаря на услугите Ви. Новият дизайн сам по себе си не е причина.
Има и обратният случай: смяна на хостинг без промяна на адресите. Google описва тази миграция отделно и съветва да свалите стойността TTL на DNS записите до ниска стойност, например няколко часа, поне седмица преди преместването. След пускането обходата на Googlebot обикновено спада за кратко и след няколко дни се покачва отново. Какво да проверите при самата смяна на доставчик, описваме в статията за домейна и хостинга на фирмата.
Как изглежда правилната карта на пренасочванията?
Картата е таблица с две колони: стар адрес и нов адрес. По един ред за всеки стар адрес. Това е цялата идея и точно тук се допускат повечето грешки.
- Едно към едно: всеки стар адрес води към новата страница със същото съдържание, а не към раздел или към списък.
- Постоянно пренасочване от сървъра: Google посочва 301 и 308 като постоянни. Временните 302, 303 и 307 показват изходната страница в резултатите, а постоянните показват целевата.
- Кратки вериги: Googlebot следва до 10 последователни пренасочвания, но Google съветва веригите да са под 5, а по възможност не повече от 3.
- Изтрито съдържание: страници, които не се местят никъде, връщат 404 или 410, а не пренасочване.
Какво да не правите? Google пише изрично да не пренасочвате много стари адреси към един неподходящ адрес, например към началната страница на новия сайт, защото това обърква хората и може да бъде прието за soft 404. Изключението е ясно: когато наистина сте обединили няколко стари страници в една нова, пренасочването натам е правилно.
Съвет от ScaleLab: Дайте картата на разработчика като файл с две колони, а не като списък в имейл. После проверете 20 реда на случаен принцип със собствения си браузър и още веднъж след пускането, защото правилото за пренаписване обикновено работи за модела, но не и за изключенията.
Какво да запазите от съдържанието и как да подредите canonical и hreflang?
Новият сайт често идва с нови текстове. Пренаписването на страница, която вече носи запитвания, е отделно решение и не е задължителна част от редизайна.
- Заглавия и текстове: запазете темата и обхвата на страницата. Ако страницата отговаряше на конкретен въпрос, новата версия също трябва да му отговаря.
- Каноничен адрес: Google съветва всяка страница да сочи сама себе си с rel canonical, с пълен адрес. Указването на каноничен адрес обаче е подсказка, а не правило: Google може да избере друга страница.
- Не смесвайте сигналите: пренасочването и каноничният адрес са силни сигнали, адресът в sitemap файла е слаб. Противоречащи си указания през различни техники само объркват картината.
- hreflang за двуезичен сайт: всяка езикова версия изброява и себе си, и останалите. Ако двете страници не сочат една към друга, указанията се пренебрегват. Стойността x-default служи за посетител, чиито настройки не отговарят на нито един от езиците Ви.
При редизайн на български и английски сайт честа грешка е да се обновят адресите в пренасочванията, но да останат старите адреси в hreflang. Проверете и двете.
Кои настройки от тестовия сайт спират новия?
Тестовият сайт се пази от търсачките, докато се строи. Проблемът идва, когато тази защита остане след пускането.
- robots.txt не крие страница от Google: според документацията той служи основно да не претоварвате сайта със заявки. Забранена в него страница може да се появи в резултатите, ако други сайтове препращат към нея.
- Капанът с noindex: ако страницата е забранена в robots.txt, обхождащият изобщо няма да види правилото noindex и страницата пак може да се показва. Затова двете не се комбинират.
- Списък за деня на пускането: Google съветва още при подготовката да си водите списък на адресите, от които трябва да се махне noindex в деня на пускането.
- Нов sitemap файл: подайте го в Search Console и махнете стария. Google използва стойността lastmod само ако тя е последователна и проверима, а priority и changefreq не се използват изобщо.
Съвет от ScaleLab: В деня на пускането отворете robots.txt на новия адрес и проверете ръчно дали правилото, което пазеше тестовия сайт, е махнато. Тази проверка отнема минута, а пропускът ѝ спира индексирането на целия сайт.
Смяна на домейн: как работи инструментът за смяна на адрес?
Когато сменяте домейна или поддомейна, Search Console има инструмент за смяна на адрес. Условията са конкретни и си струва да ги знаете предварително.
- Само на ниво домейн: инструментът мести example.com или m.example.com, но не и адреси на ниво папка.
- Собственост и върху двата сайта: трябва да сте потвърден собственик на стария и на новия сайт в един и същ акаунт.
- Пренасочване от началната страница: нужно е постоянно пренасочване от старата начална страница към новата.
- 180 дни: Search Console посочва, че действието продължава 180 дни след започването на миграцията, а пренасочванията се пазят поне толкова, и по-дълго, ако все още идва трафик.
Инструментът не се използва при преминаване от HTTP към HTTPS, при смяна между www и без www на същия домейн и при преместване на част от страниците. Указанията за преместване на сайт пък съветват пренасочванията да се пазят колкото е възможно по-дълго, като правило поне една година. Когато двата срока се разминават, придържайте се към по-дългия.
Отделно е инструментът за премахване на съдържание от резултатите. Той е временен: заявката важи около шест месеца и не спира обхождането, а само показването. Той не е начин за миграция.
Какво да проверявате в първите 30 дни?
Планът по-долу е наша препоръка, а не правило на Google. Google посочва, че при средно голям сайт преместването на повечето страници отнема няколко седмици, при по-големи сайтове повече, а видимостта може временно да се колебае.
Ден 1: проверете достъпа и пренасочванията
Отворете robots.txt, проверете дали noindex е махнат, минете през 20 реда от картата и проверете дали формите изпращат запитвания. Дайте новия sitemap файл в Search Console.
Дни 2 до 7: следете грешките, не позициите
Гледайте отчета за индексирането и логовете на сървъра за неочаквани грешки. Позициите през тази седмица не казват нищо.
Дни 8 до 30: сравнете страница по страница
Сравнете кликовете по страница с записаното преди старта. Търсете страници, които са изчезнали от отчета, а не общия сбор. Ако в същия период е имало обновление на алгоритъма, разделете двете причини: как се чете спад след обновление, описваме в статията за действията след Google core update.
Помнете и че по-малко кликове при същите позиции може да имат и друга причина, различна от миграцията. Какво се променя в резултатите и как да го четете, разглеждаме в статията за спада на органичния трафик при същите позиции. Затова отчитайте запитванията, а не само посещенията: как изглежда такъв отчет, описваме в раздела за месечния отчет.
Техническата основа, картата на пренасочванията и съдържанието са част от работата по SEO оптимизация: пречките пред обхождането се отстраняват първи, а резултатът се отчита по запитванията от търсене без реклама.
Често задавани въпроси
Задължително ли пада трафикът след редизайн?
Не е задължително, но колебания са нормални. Google посочва, че при средно голям сайт преместването отнема няколко седмици и че видимостта може временно да се колебае, докато класирането се уталожи. Ако спадът продължава и след това, проблемът обикновено е в пренасочванията или в блокирано обхождане.
Колко дълго да пазя пренасочванията?
Указанията за преместване на сайт съветват да ги пазите колкото може по-дълго, като правило поне една година. Инструментът за смяна на адрес посочва минимум 180 дни, и по-дълго, ако все още имате трафик към старите адреси.
Може ли canonical да замени пренасочването?
Не. Каноничният адрес е силен сигнал, но остава подсказка, а Google може да избере друга страница. Когато старата страница трябва да изчезне, правилното решение е постоянно пренасочване.
Трябва ли да подам инструмента за смяна на адрес, ако минавам на HTTPS?
Не. Инструментът е само за смяна на домейн или поддомейн. Преминаването към HTTPS и смяната между www и без www не се подават през него.
Какво да направя със страници, които махам съвсем?
Оставете ги да връщат 404 или 410. Не ги пренасочвайте към началната страница: Google предупреждава, че много стари адреси към един неподходящ адрес объркват хората и може да бъдат приети за soft 404.
Източници
- Google Search Central: Site Moves and Migrations (обновена на 20 август 2026 г.)
- Google Search Central: Changing Your Web Hosting and SEO (обновена на 10 декември 2025 г.)
- Google Search Central: Redirects and Google Search (обновена на 14 април 2026 г.)
- Google Search Central: What is canonicalization (обновена на 20 август 2026 г.)
- Google Search Central: How to specify a canonical URL (обновена на 10 юли 2026 г.)
- Google Search Central: Tell Google about localized versions of your page (обновена на 22 декември 2025 г.)
- Google Search Central: Introduction to robots.txt (обновена на 10 декември 2025 г.)
- Google Search Central: Block Search indexing with noindex (обновена на 10 декември 2025 г.)
- Google Search Central: Build and submit a sitemap (обновена на 8 юли 2026 г.)
- Google Search Central: Influencing your title links in search results (обновена на 10 декември 2025 г.)
- Google Search Central: Remove a page hosted on your site from Google (обновена на 10 декември 2025 г.)
- Search Console Help: Change of Address tool