Как да мигрирате домейн, без да сринете класирането си в търсачките

Смяната на домейн е един от малкото SEO проекти, при които технически малка грешка може много бързо да стане силно видима. Липсващо пренасочване, блокиран път за обхождане или забравен canonical може да превърне един иначе ясен rebrand в седмици на нестабилни класирания.

Известно движение е нормално. Търсачките имат нужда от време, за да обходят старите URL адреси, да открият пренасочванията, да обработят сигналите и да позиционират новия домейн в индекса. Целта не е да избегнете всеки спад. Целта е миграцията да бъде скучна: един стар URL води към един еквивалентен нов URL, сървърът отговаря ясно и нищо важно не изчезва.

Започнете с инвентаризация, не с правило за пренасочване

Най-честият провал при миграция е третирането ѝ като задача по сървърна конфигурация. Тя не е такава. Това е задача по информационна архитектура, която просто завършва със сървърна конфигурация.

Преди да пипате DNS, изгответе списък с URL адресите, които имат значение:

• URL адреси, които получават органичен трафик
• URL адреси с външни backlinks
• URL адреси, които конвертират, генерират leads или поддържат кампании
• Canonical URL адреси, които в момента са във вашия XML sitemap
• PDFs, изображения и файлове за изтегляне, към които има външни връзки
• Ценни legacy URL адреси, които може да не се появяват в текущата навигация

За всеки стар URL задайте дестинация в новия домейн. В повечето случаи тази дестинация трябва да бъде същата страница със същото намерение. Ако /pricing стане https://newdomain.com/pricing, това е просто. Ако три стари продуктови страници се сливат в един нов guide, документирайте това решение съзнателно.

Избягвайте мързеливия модел: пренасочване на всичко към новата начална страница. Удобно е, но изхвърля релевантността. И търсачките, и потребителите очакват дестинацията да отговаря на същата нужда като оригиналния URL.

Запазете URL структурата, когато можете

Миграцията на домейн е по-лесна, когато пътищата останат стабилни. Преминаването от oldsite.com/blog/example към newsite.com/blog/example е много по-чисто, отколкото едновременно да сменяте домейн, CMS, slugs, структура на папките и съдържание.

Понякога redesign или CMS migration прави URL промените неизбежни. Ако е така, разделете решенията:

1. Какво се променя, защото домейнът се променя?
2. Какво се променя, защото структурата на сайта се променя?
3. Какво се изтрива, слива или пренаписва?

Колкото повече променливи въвеждате, толкова по-трудно става да диагностицирате проблеми по-късно. Ако миграцията е важна и текущият сайт се представя добре, помислете първо да преместите домейна, а redesign да направите по-късно.

Използвайте постоянни пренасочвания с един hop

За истинска миграция на домейн използвайте server-side 301 или 308 redirects от старите URL адреси към новите им еквиваленти. Временните пренасочвания са за временни ситуации. JavaScript redirects, meta refreshes и soft redirects са по-слаби сигнали и по-лесно се чупят.

Целите за пренасочванията са прости:

• Всеки важен стар URL връща постоянно пренасочване.
• Всяко пренасочване води директно към крайната дестинация.
• HTTP се пренасочва чисто към HTTPS.
• www и non-www вариантите се обработват последователно.
• Пренасочванията не зависят от крехко поведение на query-string, освен ако не е необходимо.

Лоша верига изглежда така:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Това може в крайна сметка да стигне до правилната страница, но е бавно, по-трудно за обхождане и по-вероятно да скрие грешки. Стремете се към един hop от всеки стар вариант до крайния нов URL.

Когато валидирате поведението, проверявайте реалните HTTP отговори, вместо да се доверявате на това, което показва браузърът. Нашият guide за debugging redirects and HTTP headers in production е полезен тук, защото браузърите са твърде любезни: те следват веригата и скриват разхвърляните части.

Подгответе DNS и сертификатите преди старта

DNS не прехвърля директно класирания, но лошият DNS може да направи миграцията да изглежда счупена. Намалете TTL стойностите преди launch window, така че промените да се разпространяват по-предвидимо. Потвърдете, че новият домейн има правилни записи за web traffic, email и всички необходими subdomains.

Нуждаете се и от валидни TLS сертификати за двата домейна. Това лесно се пропуска. Старият домейн все още трябва да обслужва HTTPS пренасочвания след миграцията. Ако сертификатът му изтече, потребителите и crawlers може да попаднат на browser warnings, преди изобщо да достигнат новия сайт.

Ако преместването засяга email, не го третирайте като второстепенна мисъл. Промените на домейн често чупят SPF, DKIM, DMARC, MX records, tracking links и transactional mail. За опресняване на важните записи вижте нашия developer-friendly guide за MX, SPF, DKIM, and DMARC.

Проверете canonicals, вътрешните връзки и sitemaps

След старта новият домейн трябва да се държи така, сякаш винаги е бил canonical домът на съдържанието.

Това означава:

• Canonical tags сочат към новите URL адреси, не към стария домейн.
• Вътрешните връзки използват новия домейн или root-relative paths.
• XML sitemaps съдържат само крайни, indexable нови URL адреси.
• hreflang annotations, ако се използват, реферират към новите URL адреси.
• Open Graph, structured data и alternate links са актуализирани.
• Robots.txt не блокира важни секции.

Не публикувайте sitemap, пълен със стари URL адреси, и не очаквайте пренасочванията да го изчистят. Sitemap трябва да бъде списък с URL адреси, които искате да бъдат индексирани. След миграция това означава крайни URL адреси в новия домейн.

Внимавайте и за canonical противоречия. Страница, която се пренасочва от стария към новия домейн, но има canonical, сочещ обратно към стария домейн, изпраща смесени сигнали. Търсачките обикновено могат да се справят с известна непоследователност, но не бива да ги карате да го правят.

Не променяйте всичко в деня на старта

Миграцията вече е достатъчно голямо събитие. Ако е възможно, избягвайте да я комбинирате с мащабно орязване на съдържание, пренаписване на templates, промени в навигацията, промени в JavaScript rendering или нов performance profile.

Това не е суеверие. Това е дисциплина при debugging. Ако класиранията паднат след старта, трябва да знаете дали причината е redirect mapping, crawl access, променено съдържание, по-бавно rendering, липсващи structured data или нещо друго.

Дръжте първоначалния старт възможно най-близо до стария сайт на практика. След като новият домейн се стабилизира, правете по-големи editorial и design промени на по-малки партиди.

Кажете на търсачките какво се е променило

В Google Search Console верифицирайте и стария, и новия домейн. След това използвайте инструмента Change of Address, когато преместването е промяна на ниво домейн и съдържанието се мести към нов домейн. Изпратете новия sitemap след старта.

Това не заменя пренасочванията. Подкрепя ги. Търсачките все още се нуждаят от crawlable, persistent redirects, за да разберат mapping-а на ниво URL.

За Bing и други търсачки използвайте техните webmaster tools, когато са налични. Актуализирайте и местата, които контролирате: social profiles, business listings, ad destinations, email footers, документация, partner links и canonical references в syndicated content.

Външните връзки няма да бъдат актуализирани всички и това е нормално. Но най-важните трябва да бъдат. Ако основен партньор, app marketplace, documentation portal или press page сочи към стария домейн, поискайте актуализация.

Следете правилните неща след старта

Първите няколко дни след миграцията трябва да бъдат активен мониторинг, не празнуване.

Проверявайте:

• Server logs за crawl activity в стария и новия домейн
• 404s и неочаквани 5xx errors
• Redirect chains и loops
• Indexing status в Search Console
• Sitemap discovery and processing
• Organic landing pages и query patterns
• Conversion paths, които зависят от стари URL адреси
• Analytics filters и referral exclusions

Очаквайте шум в отчетите. Някои analytics tools третират новия домейн като нова property, освен ако не са конфигурирани правилно. Някои dashboards сравняват трафика на стария домейн с трафика на новия домейн и правят миграцията да изглежда по-лоша, отколкото е.

Видимостта в търсенето може да варира няколко седмици. Това, което не искате, е модел, при който ценни стари URL адреси се обхождат многократно, но не се пренасочват правилно, или при който нови страници се откриват, но се маркират като дубликати на стария домейн.

Performance също не бива да се игнорира. Ако новият домейн стартира с по-тежки templates, счупено caching или неоптимизирани assets, потребителите може да усетят миграцията като забавяне. Ако използвате Lighthouse като част от проверките си, четете го с приоритети наум; нашата статия за how to read a Lighthouse report without panicking обяснява как да отделите значимите проблеми от шума.

Запазете стария домейн за дълго време

Не оставяйте стария домейн да изтече, след като миграцията „проработи“. Дръжте го регистриран, поддържайте сертификатите валидни и оставете пренасочванията да работят възможно най-дълго. На практика това често означава години.

Старите връзки продължават да съществуват в blog posts, bookmarks, документация, PDFs, emails и social posts. Пренасочванията са мостът между този исторически footprint и новия домейн. Изключването им твърде рано прекъсва пътищата на потребителите и прахосва натрупаните сигнали.

Запазете и копие на вашата redirect map и launch notes. Шест месеца по-късно, когато някой попита защо legacy URL се държи по определен начин, ще се радвате, че сте го документирали.

<!-- tool-cta:start -->

💡 Опитайте това: След преминаването проследете старите си URL адреси чрез Redirect Checker, за да потвърдите, че всеки от тях се разрешава с един-единствен 301 преход към правилната нова страница.

<!-- tool-cta:end -->

Разумен контролен списък за миграция

Преди старта:

• Верифицирайте и двата домейна в Search Console.
• Crawl-нете текущия сайт и експортирайте важните URL адреси.
• Изградете one-to-one redirect map.
• Намалете DNS TTLs.
• Подгответе TLS certificates за стария и новия домейн.
• Актуализирайте canonicals, internal links, hreflang, structured data и sitemaps.
• Тествайте redirects в staging или контролирана среда.

В деня на старта:

• Deploy-нете redirects.
• Потвърдете поведението от HTTP към HTTPS.
• Тествайте важни URL samples от всеки template type.
• Изпратете новия sitemap.
• Използвайте инструмента Change of Address, където е уместно.
• Следете server errors, redirect loops и blocked resources.

След старта:

• Следете crawl errors и indexing reports.
• Актуализирайте важни външни връзки, където можете.
• Сравнявайте трафика по intent на landing page, не само по общи стойности за домейна.
• Дръжте redirects активни за неопределено време.
• Отложете несвързани redesign или content experiments, докато преместването се стабилизира.

Миграциите на домейни не са безрискови, но са управляеми. Класиранията обикновено страдат, когато миграцията изпраща неясни сигнали: липсващи redirects, променено съдържание, противоречиви canonicals, blocked crawlers или забравен стар домейн. Дайте на търсачките и потребителите чиста карта и преместването става много по-малко драматично.