Listă de verificare pentru migrarea site-ului: de la T-4 săptămâni la ziua 45

Un 301 care se termină într-un 404 nu păstrează nimic

Unele echipe trimit fiecare URL vechi către noua acasă și lasă paginile destinație să expire mai târziu. Redirectul în sine funcționează. De aceea, această obișnuință este riscantă, deoarece fiecare pas pare curat într-un jurnal, în timp ce pagina de la capăt răspunde cu un 404.

Să presupunem că muți un magazin pe un domeniu nou și păstrezi doar produsele care se mai vând. Paginile de categorie care conțineau majoritatea linkurilor externe acum se îndreaptă către ceva inutil. Numără URL-urile linkate extern înainte de a retrage orice. Fă acest lucru primul pas. O pagină cu domenii care trimit linkuri are nevoie de o țară vie pe același subiect, nu de un gest de neputință.

Păstrează regula scurtă: un singur pas, apoi un 200 final. Orice altceva este o scurgere pe care ai ales-o.

Ce protejează un 301 într-un singur pas către o pagină activă

Valoarea unui link stă pe URL-ul către care indică. Un redirect transferă acea valoare doar dacă adresa către care ajunge răspunde și încă se potrivește cu subiectul. Un produs mutat către același produs în noul catalog trece acest test, în timp ce un produs trimis către pagina principală de obicei nu, chiar dacă era pagina către care toată lumea linka.

Re-verifică statusul final după fiecare modificare de șablon. Un redirect care funcționa la lansare se poate termina într-un 404 după o lansare ulterioară, când cineva elimină o categorie în timpul unei curățenii a meniului.

Când un 410 este răspunsul onest

Unele URL-uri vechi nu aveau linkuri, nici vizite și nici un înlocuitor real. Pentru acestea, un 404 clar sau un 410 este mai onest decât un redirect către o pagină care nu răspunde la întrebarea pe care o făcea cea veche. Un redirect către o pagină nelegată este adesea tratat ca un soft 404, deci nu salvează nimic.

Scrie decizia pentru fiecare grup de URL-uri, cu motivul alături. Un dosar de tutoriale retrase primește un răspuns diferit de la un dosar de pagini cu patruzeci de domenii care trimit linkuri, și vei dori să explici acea diferență unui coleg peste șase luni.

Verificarea ultimului pas, nu doar al primului

Majoritatea testelor de redirect se opresc la primul răspuns, ceea ce este locul greșit de a te opri. Urmează lanțul până la capăt, apoi înregistrează numărul de pași și statusul final lângă URL-ul vechi. Un lanț de doi pași nu este rupt, dar adaugă întârziere și un loc suplimentar în care o regulă poate eșua.

Dacă un script este inaccesibil, un spreadsheet și câteva apeluri curl vor face treaba. Pagina cu scripturi API are o versiune pe care o poți programa.

Sitemape și solicitări manuale după lansare

Păstrează sitemap-ul vechi accesibil timp de câteva săptămâni după mutare. Crawlerele care revizitează gazda veche pot încă găsi acele adrese într-o singură listă, ceea ce grăbește prima trecere prin redirecturi.

Solicitările manuale sunt un instrument diferit. Folosește-le pentru puținele pagini care contează cel mai mult, nu pentru sute de URL-uri trimise una câte una. O pagină solicitată fără linkuri interne și cu un conținut subțire tinde să dispară din nou, deci solicitarea este bună doar cât este pagina din spatele ei.

Așteptarea este un plan valid. Dă timp crawlului, apoi evaluează-l pe baza datelor.

Păstrarea sitemap-ului vechi listat pentru o perioadă

Păstrează sitemap-ul vechi în Search Console până când URL-urile vechi încetează să apară în statisticile de crawl. Apoi, elimină-l intenționat și notează data în jurnalul de migrare.

Nu îl elimina în ziua lansării doar pentru a face proprietatea să arate îngrijită. Eliminarea timpurie ascultă singura listă care numește fiecare URL vechi pe care încă trebuie să îl urmărești.

Solicitarea indexării pentru paginile care conțin linkuri

Alege cele douăzeci de URL-uri noi cu cele mai multe linkuri externe, folosind aceeași uniune pe care ai construit-o pentru harta de redirect și solicită-le manual. Efortul urmează apoi riscul în loc de dimensiunea site-ului.

Dacă o pagină solicitată lipsește încă după câteva săptămâni, uită-te la pagină înainte de a cere din nou. Verifică linkurile sale interne, canonical-ul și conținutul. O a cincea solicitare nu schimbă nimic.

Cât timp înainte ca mutarea să poată fi evaluată

Evaluează mutarea de la a doua extragere de linkuri, nu de la prima. Indexul nostru se reîmprospătează aproximativ o dată pe lună, deci o extragere de la ziua trei arată în mare parte imaginea din luna trecută. Rulează a doua extragere după reîmprospătare și folosește-o pentru a găsi toate backlink-urile către un site web pe noua gazdă.

Raportul Pages și datele despre linkuri răspund la întrebări diferite. Citește-le alături, nu ca verdicturi concurente asupra aceleiași mutări.

Urmărirea site-ului după lansare, nu doar înainte

Un audit pre-lansare înregistrează ce era adevărat în ziua în care a fost rulat. Majoritatea daunelor de lansare apar mai târziu, după o actualizare de plugin, o modificare a unei reguli CDN sau un șablon care atinge o setare pe care nimeni nu a revizuit-o.

Tratează supravegherea post-lansare ca pe un set de diferențe mici față de un punct de referință salvat. Nu este nevoie de un dashboard. Un program și un dosar de fișiere cu date vor face treaba.

Ce ar trebui să compare o supraveghere săptămânală

Alege verificările care ar afecta cel mai mult dacă s-ar schimba și rulează-le în aceeași zi în fiecare săptămână.

• Cod de status și URL final pentru top 50 URL-uri vechi linkate
• robots.txt și tag-ul meta robots pe șabloanele principale
• Numărul de URL-uri 200 active împotriva numărului din noua sitemap
• Etichete canonical pe pagina principală, o categorie și un articol

De ce un audit unic ratează derivația lentă

Derivația setărilor după lansare. Un flag de test lăsat activ, un plugin care rescrie permalinks sau un redirect adăugat pentru a repara o pagină pot anula fiecare câte o parte din plan. Un audit luat în ziua lansării nu le poate vedea pe niciunul.

O diferență programată poate. Păstrează fișierele de bază în controlul versiunilor și compară outputul fiecărei săptămâni cu ele, astfel încât o modificare neașteptată să fie vizibilă în ziua în care apare.

Subdomenii, eliminări și schimbări de domeniu la nivel de site

Unele echipe mută o secțiune pe un subdomeniu și indexează doar paginile sale populare. Acest lucru poate funcționa. Costul este că linkurile destinate paginilor mai puțin populare ajung acum pe o gazdă cu mai puțină istorie, deci numără-le înainte de a tăia ceva.

Solicitările de eliminare sunt mai înguste decât par. Search Console aplică o eliminare la proprietatea în care o depui, deci o solicitare făcută pe un subdomeniu nu acționează asupra domeniului principal. Verifică proprietatea mai întâi. Apoi depune-o și păstrează ambele verificate.

Indexarea doar a paginilor populare pe un subdomeniu

Începe cu linkurile pe URL în acea secțiune. Paginile care conțin linkuri externe dar puțin trafic sunt primele pe care o regulă doar-pagini-populare le-ar ascunde. Păstrează-le crawlabile sau redirectează fiecare către cea mai apropiată pagină populară și scrie motivul alături de regulă.

Unde site-ul principal linkază către subdomeniu decide cât de ușor sunt găsite paginile sale. Listează acele linkuri înainte de a alege care pagini rămân ascunse, deoarece o pagină către care site-ul principal nu linkază niciodată este greu de atins în orice caz.

O schimbare de domeniu la nivel de site, pagină cu pagină

O regulă la nivel de gazdă gestionează rădăcina, dar o schimbare de domeniu are nevoie și de o hartă la nivel de cale. Când prima parte a URL-ului se schimbă și slug-ul rămâne același, un schimb de gazdă acoperă majoritatea paginilor, iar excepțiile au nevoie de linii proprii.

Construiește lista din paginile linkate mai întâi, apoi potrivește fiecare cale veche cu cea nouă. Rețeta pentru harta de redirect arată cum să clasifice acea listă după linkuri.