Analizați modificările de linkuri în jurul unei migrări

Construiți harta de redirect înainte de lansare

Harta de redirect este partea unei mutări pe care oamenii subestimează. Destinațiile sunt cele mai importante. Înainte de a analiza datele de linkuri după o mutare, URL-urile vechi trebuie să aibă o destinație clară, deoarece acestea sunt adresele către care indică deja linkurile dumneavoastră.

One-to-one bate un dump pe pagina de start

Trimiterea a sute de URL-uri vechi nepotrivite către pagina de start spune foarte puțin motoarelor de căutare și vizitatorilor. Relevanța este testul. Mapați fiecare URL vechi cu valoare mare către noua pagină cea mai apropiată și trimiteți restul către o secțiune care încă se potrivește cu subiectul lor.

Exportați mai întâi URL-urile vechi cu codurile lor de status. Păstrați acel fișier în siguranță. Acest fișier este checklist-ul și arată care pagini au câștigat linkurile.

Unde o pagină nu are o potrivire apropiată, specificați acest lucru în hartă și trimiteți-o către secțiunea cea mai apropiată, cu o notă. Celulele goase ascund decizii. O celulă goală în tabel este o decizie pe care nimeni nu a luat-o.

Aplatizați lanțurile înainte de lansare

Un redirect care trece prin două reguli anterioare înainte de a ajunge la noua pagină adaugă întârziere și risc. Lanțurile sunt ușor de creat când o a doua migrare se suprapune peste prima, așa că revizuiți harta înainte de fiecare comutare în loc să presupuneți că este încă curată. Fiecare hop suplimentar are un cost. Solicitați fiecare URL vechi o dată după comutare și confirmați că răspunde cu un singur hop.

Reparați devreme. Reparați lanțurile în propria hartă, nu unul câte unul după lansare, astfel încât lista să rămână scurtă.

Păstrați căile care încă funcționează

Schimbarea structurii URL într-un redesign este cea mai evitabilă pierdere. Fiecare modificare a unei căi este, de asemenea, o modificare a fiecărui link care indică către ea, iar acele linkuri sunt în afara controlului dumneavoastră. Păstrați ceea ce funcționează. Dacă o cale încă funcționează, păstrați-o și modificați doar ceea ce mutarea vă forțează să modificați.

Mai puține redirectări, mai puține erori. Fiecare cale pe care o păstrați este un link care nu a avut nevoie niciodată de un redirect.

O cale păstrată înseamnă că rândurile vechi de anchor text continuă să indice undeva util, ceea ce este un lucru în moins de reconstruit în foaia de calcul. Mai puțină reconstrucție mai târziu.

Ce să expectați ulterior

Acestea fac munca grea, iar un 301 de la URL-ul vechi la cel nou permite linkurilor vechi să continue să funcționeze. Menținerea unui redirect per URL vechi, fără lanț între ele, este cea mai simplă modalitate de a păstra valoarea fiecărui link intactă. Redirectări. Lanțurile de trei sau patru hop-uri încetinesc crawlerele și sunt cele mai bine aplatizate.

Anchor text-ul nu se schimbă când un URL se mută, deoarece textul trăiește pe pagina care face link. Ceea ce se schimbă este numărul de destinații: tabelul dumneavoastră de top-pagini va arăta gazda veche scăzând și cea nouă crescând în câteva actualizări lunare. Destinațiile se mută lent.

O surpriză comună este ștergerea prea devreme a platformei vechi. Nu faceți asta. Squarespace, Wix și gazde similare dețin adesea regulile de redirect, așa că anularea planului poate elimina aceste reguli, iar linkurile vor indica apoi către un capăt mort până când reconstruiți regulile altundeva.

Hreflang și canonicalurile merită o privire. Neconcordanțele sunt comune. După o migrare de CRA la Next.js, de exemplu, site-urile ajung adesea cu tag-uri canonical care nu sunt de acord cu seturile lor hreflang, iar linkurile se împart între două versiuni ale unei pagini.

Dacă numerele nu sunt de acord după mutare, verificați tabelul de depanare înainte de a presupune că linkurile au fost pierdute. O simplă actualizare lunară explică multe goluri. Golurile sunt adesea o chestiune de timp.

Expectați prima comparație curată cu aproximativ două actualizări lunare după lansare și notați data fiecărei actualizări în foaia dumneavoastră astfel încât o lună plată să nu fie confundată cu una blocată. Dați-i timp. Ahrefs sau Semrush pot completa golul cu crawluri mai proaspete dacă aveți nevoie de o citire interimară.

Monitorizați ce se mută fără un anunț de lansare

Ziua de lansare are un checklist, dar mai multe probleme apar mai târziu și în liniște. Ele apar în rânduri și în index, mult după ce echipa s-a mutat la alte lucrări. Sunt ușor de ratat.

Noindex care călătorește cu o construcție de staging

O copie de staging care a fost ținută în afara căutărilor poate-și duce setările în site-ul live. Verificați tag-urile meta robots și orice antet noindex la primul crawl și eșantionați pagini din fiecare secțiune, nu doar pagina de start. Eșantionați fiecare secțiune.

Șabloanele se strică primele. Dacă o întreagă secțiune dispare din index după lansare, uitați-vă la șablonul ei înainte de a vă uita la conținutul ei.

Capturile de ecran ajută și ele. Păstrați o copie a setărilor robots din construcția de staging, de asemenea. Când ceva dispare din index, compararea celor două seturi de setări durează minute, nu o după-amiază.

Linkuri fragment care sunt indexate

Linkuri de tip jump, cum ar fi un anchor de cuprins, pot apărea ca URL-uri separate în rezultatele căutărilor. Motoarele de căutare le pliază de obicei în pagina principală, dar când nu o fac, același conținut poate apărea sub mai multe adrese. Ele împart semnalele departe de pagina principală și pot părea ca pagini duplicate într-un raport de acoperire. URL-urile hash se înmulțesc liniștit.

O versiune, o adresă. Un tag canonical care indică către o singură adresă în timp ce sitemap-ul listează alta trimite semnale mixte, iar raportul va arăta neconcordanța. Setează o singură versiune canonicală pentru fiecare pagină și confirmă că sitemap-ul listează aceeași versiune.

Verifică raportul de acoperire după lansare pentru URL-uri care conțin un hash, deoarece acestea sunt cele care se înmulțesc liniștit. Hash-urile sunt vinovatele.

Un subdomeniu care devine domeniul principal

Mutarea unui site de pe un subdomeniu de staging pe domeniul principal aduce duplicate ale sale, deoarece ambele versiuni pot rămâne accesibile pentru o vreme. Decideți care gazdă este canonicală înainte de lansare. Alegeți gazda devreme.

O singură gazdă, peste tot. Când o gazdă se schimbă într-un loc și nu în altul, versiunea mai veche poate continua să colecteze linkuri timp de luni fără ca cineva să observe. Apoi, mențineți sitemap-ul, tag-urile canonical și orice seturi hreflang indicând către acea singură gazdă.

Linkuri do-follow care par să dispară

După un redesign, rândurile do-follow dintr-un instrument pot scădea brusc, iar prima bănuială este că linkurile au dispărut. Comparați paginile top vechi cu cele noi înainte de a accepta acea bănuială, apoi verificați dacă fiecare adresă veche redirectează acum corect. Verificați înainte să vă panicați.

Reparați aceeași întâi. Un link care există încă pe pagina care face link, dar indică către o adresă moartă, este cazul de reparat primul.

Setați data devreme. Dați echipei o dată fixă pentru comparație, astfel încât nimeni să nu reexecute extragerea în fiecare zi și să citească zgomot ca știri.

Lucrul cu un developer în timpul mutării

Majoritatea muncii de redirect cade pe un developer, iar monitorizarea cade pe cineva care citește foaia de calcul. Scrierea divizării ca un tabel scurt, cu un nume în fiecare celulă, este adesea suficient pentru a opri două persoane să presupună același task. Împărțiți acele roluri pe hârtie înainte de lansare, astfel încât nimeni să nu presupună că celălalt se uită. Rolurile au nevoie de nume.

Dați developerului o hartă, nu o listă de sarcini

O listă de sarcini îi spune unui developer ce să facă, în timp ce o hartă arată către unde merge fiecare adresă veche. Trimiteți tabelul one-to-one cu codurile de status și motivul fiecărui rând, astfel încât cazurile limită să primească o decizie, nu o presupunere. Deciziile bat presupunerile.

Planurile de testare vin primele. Cereți un plan de testare scurt care începe cu adresele vechi din fișierul de top pages.

Acelați cine citește fișierul lunar

Prima comparație curată vine cu aproximativ două actualizări după lansare, iar fișierul va avea nevoie de un cititor. Prima citire după lansare este de obicei zgomotoasă, iar un cititor care știe acest lucru va evita să reacționeze la o lună neobișnuită. Numeți acea persoană, ziua în care o deschide și foaia de calcul unde merge rezultatul. Cineva trebuie să preia responsabilitatea.

Datele rezolvă întrebarea. Scrierea datei de actualizare lângă fiecare fișier transformă o îngrijorare despre un index blocat într-un fapt simplu despre calendar. O lună plată este ușor de citit greșit ca una blocată dacă cineva nu notează datele de actualizare.

Cereți acelei persoane să scrie o linie per actualizare, chiar și când nu s-a schimbat nimic, astfel încât fișierul să mențină un record continuu. O linie de fiecare dată.

Planificați rollback-ul înainte de lansare

Dacă noul host strică o cale critică, echipa are nevoie de o cale de întoarcere care a fost testată în avans. Scrieți pașii, inclusiv cine poate comuta și cum se comportă redirectările în timp ce sunt anulate. Repetați înainte de lansare.

Scrieți rollback-ul. Un rollback care există doar în capul unei singure persoane nu este un plan.