Миграции на сајт: Како да смените платформа или домен без да го изгубите SEO-то

Миграцијата на сајт е еден од ретките проекти каде што и совршено извршување не е доволно — можете да го изведете секој видлив дел беспрекорно и сепак да видите пад на органскиот сообраќај од 40% во неделите по лансирањето, зашто штетата се случува на места што никој не ги прикажува на состанок со засегнати страни. Пребарувачите не го гледаат новиот сајт како надградба на стариот по стандард. Тие гледаат поинакво множество URL-адреси и мора експлицитно и целосно да им се каже како старите се спарени со новите. Прескокнете го тоа, дури и делумно, и годините акумулиран сигнал за рангирање се третираат како изгубени, а не преместени.

Ова постојано се јавува: ребрендирање што менува домен, замена на застарен CMS со нешто современо, редизајн што „ја чисти“ URL структурата на патот. Сите три се добри причини за миграција. Ниту една не е изземена од механиката подолу.

Мапирајте ја секоја URL-адреса пред да го допрете стариот сајт

Најчестиот пропуст е започнување на листата за миграција откако стариот сајт веќе е отстранет. Ви треба целосна листа на секоја индексирана URL-адреса на тековниот сајт — извлечете ја од извештајот за покриеност во Google Search Console, вашата XML карта на сајтот, серверските логови и цело поминување (Screaming Frog или слично), зашто ниту еден извор сам по себе не е целосен. За секоја URL-адреса на таа листа, одлучете каде оди на новиот сајт пред лансирањето, не откако некој ќе забележи скок во 404 грешки.

Старите URL-адреси што немаат директен еквивалент сепак им треба дестинација — најблиску релевантната страница, не почетната страница по стандард. Шема каде сѐ се пренасочува кон почетната страница речиси не ја зачувува оригиналната вредност за рангирање и на пребарувачите им изгледа како шема на мек-404 низ целиот сајт.

Пренасочувајте со 301, не со мета освежување или JavaScript

Постојаното 301 пренасочување е единствениот механизам што сигурно го пренесува сигналот за рангирање од старата на новата URL-адреса. Пренасочувањата на страна на клиентот — мета освежување ознака, промена на location.href преку JavaScript — доцна се откриваат од роботите за собирање податоци, понекогаш воопшто не, и пренесуваат малку или ништо од авторитетот на оригиналната страница. Ако вашата нова платформа го отежнува пренасочувањето на серверско ниво (некои статични поставки го прават тоа), решете го тоа на ниво на хостинг или CDN наместо да испорачате JS пренасочување и да се надевате.

Синџирите на пренасочувања се вториот најчест пропуст: URL-адреса А пренасочува кон Б, која пренасочува кон В, зашто две миграции се случиле две години една по друга, а никој не го исчистил првото множество. Секој чекор во синџир губи малку авторитет и додава доцнење; проверувајте ја мапата на пренасочувања повремено и собирајте ги синџирите во еден чекор од оригиналната директно до тековната URL-адреса.

Совпаѓајте содржина, не само URL структура

Пренасочувањето мапира URL-адреса кон URL-адреса, но она што навистина ги зачувува рангирањата е дали темската релевантност преживува преместувањето. Ако /services/web-design стане /what-we-do/design, а дестинациската страница покрива значително поинаков опсег, пренасочувањето е технички исправно, а практично бескорисно — пребарувачите ја преоценуваат релевантноста според вистинската содржина на новата страница, не според постоењето на пренасочувањето. Кога миграцијата е и целосна преработка на содржината, направете ја вежбата за мапирање на содржина експлицитно: чија публика, клучни зборови и намера од старата страница навистина ги служи новата. Ако одговорот е „ниту еден, доволно блиску“, тоа старо рангирање нема да се пренесе без разлика што вели мапата на пренасочувања.

Ажурирајте ги внатрешните линкови, не потпирајте се само на пренасочувањата

Пренасочувањата се мрежа за безбедност за надворешни линкови и стари обележувачи што не се под ваша контрола. Внатрешните линкови се ваши за директно поправање, а нивно оставање кон стари URL-адреси — дури и оние што правилно пренасочуваат — додава непотребен чекор на секоја внатрешна патека за собирање податоци и го разводнува капиталот на линкот што инаку би течел директно кон дестинациската страница. Пред лансирањето, поминете го новиот сајт и потврдете дека внатрешната навигација, футерот и линковите во содржината водат кон конечните URL-адреси, не кон изворите на пренасочување.

Повторно поднесете, не претпоставувајте

Штом новиот сајт е активен: поднесете ја новата XML карта на сајтот во Search Console, а ако доменот се сменил, користете ја алатката за промена на адреса наместо да чекате органско повторно откривање. Одржувајте го активен и следен профилот на Search Console на стариот домен — потребен ви е за да потврдите дека пренасочувањата се собираат и следат, и за да фатите грешки на URL-адреси за кои не сте знаеле дека постојат. Очекувајте привремен пад во рангирањата дури и при чиста миграција; на пребарувачите им треба време повторно да го поминат и проценат целото множество URL-адреси, а тоа доцнење е нормално, не знак дека нешто се расипало. Она што не треба да се случи е пад што не закрепнува по четири до шест недели — тоа е сигнал дека нешто во мапирањето било погрешно и вреди целосна споредба на поминувањето наспроти вашата листа URL-адреси пред миграцијата, наместо да чекате.

Третирајте го како проект со контролна точка, не како објавување

Тимовите што излегуваат од миграција со непроменет сообраќај ја третираат мапата на URL-адреси како испорака со чекор за преглед, на ист начин како што би прегледале скрипта за миграција на база на податоци — зашто функционално тоа и е. Тимовите што губат сообраќај ги третираат пренасочувањата како задача за чистење по лансирањето. Дотогаш стариот сајт е отстранет, листата на URL-адреси е реконструирана од сеќавање и празнини во аналитиката, а поправките се случуваат откако штетата веќе е видлива во рангирањата, наместо пред таа воопшто да настане.

PNK WORKS изведуваше замени на платформи и миграции на домени без падот на сообраќај што обично ги придружува. Започнете проект.