Checklist SEO pentru migrarea site-ului

O migrare de site este o schimbare controlată a platformei, domeniului, protocolului, arhitecturii informaționale, structurii URL sau sistemului de randare al unui site. Este completă doar atunci când utilizatorii, crawlerii și sistemele de analytics pot ajunge la conținutul dorit prin rute stabile, iar echipa poate demonstra că vizibilitatea valoroasă a supraviețuit.

Checklist: SEO migrare site. Cadență: începe cu 6–12 săptămâni înainte de lansare pentru un site mediu; rezervă ultimele 5 zile lucrătoare pentru o înghețare a schimbărilor, ziua lansării pentru validare cu personal și cel puțin 4 săptămâni pentru monitorizare activă. Responsabil: un singur lider de migrare răspunzător pentru întreaga lansare, sprijinit de proprietari numiți din inginerie, SEO, analytics, conținut și infrastructură.

De ce există acest checklist și de ce se aplică aici

Acest strat de control al lansării din procesul SEO consumă dovezi de accesare și indexare din auditul tehnic de bază , decizii de păstrare/comasare/eliminare din inventarul și auditul de conținut și ierarhia destinațiilor din harta topică și arhitectura informațională . Aceste rezultate trebuie să existe înainte ca redirecționările sau mediul de staging să poată fi evaluate.

Rulează-l după ce structura destinațiilor este aprobată, dar înainte ca rutele de producție să fie înghețate. Dacă rulează prea devreme, echipa mapează redirecționări către destinații care se pot schimba încă. Dacă rulează prea târziu, rutarea, șabloanele, analytics sau comunicările de lansare pot fi deja prea costisitoare de corectat în siguranță.

Harta de redirecționări este artefactul cu cel mai mare risc, deoarece leagă rutele vechi de cele noi. Fiecare URL vechi valoros ar trebui să meargă unu-la-unu către cea mai apropiată destinație care îi păstrează scopul. Nu folosi niciodată pagina principală ca soluție universală: frustrează vizitatorii și maschează destinațiile lipsă.

Intrări și ieșiri

Ieșirile sunt contractul cu operațiunile de lansare. O foaie de calcul fără proprietari, dovezi sau condiții de acceptare nu este un predat.

Checklist-ul

Fiecare element afirmă ce, de ce, cum, instrument și o condiție observabilă de finalizare. Înlocuiește un prag doar cu o regulă mai strictă sau una bazată pe un punct de referință documentat.

Faza 1: inventar pre-migrare

1. Construiește inventarul unificat de URL-uri. Ce: combină fiecare URL vechi descoperibil din accesări, sitemapuri XML, analytics, Search Console, exporturi de backlinkuri, înregistrări CMS, campanii plătite și loguri de server. De ce: nicio sursă unică nu conține fiecare URL valoros sau solicitat; o pagină absentă din navigație poate avea totuși linkuri, trafic sau importanță contractuală. Cum: normalizează protocolul, hostul, majusculele, slash-ul final, parametrii și caracterele codate, păstrând totodată valoarea sursă brută. Deduplică doar după ce înregistrezi unde a fost găsit fiecare URL. Instrument: crawler, export CMS, analytics, Search Console, date de backlinkuri și loguri. Finalizat când: fiecare sursă este datată, fiecare rând are un URL normalizat și o sursă de descoperire, duplicatele sunt rezolvate, iar totalurile pe surse se potrivesc cu inventarul final.

2. Clasifică destinația fiecărui URL. Ce: etichetează fiecare URL ca păstrează, mută, comasează, elimină sau investighează. De ce: redirecționările nu pot fi mapate corect până când decizia de conținut nu este explicită. Cum: combină trafic, conversii, backlinkuri, stare de indexare, calitate conținut, necesitate de business și intenție; înregistrează dovada și proprietarul care aprobă. Instrument: foaie de calcul inventar și audit de conținut. Finalizat când: 100% dintre URL-urile din sfera de aplicare au o destinație, un proprietar, o destinație sau un motiv de eliminare și niciun rând „investighează” nerezolvat la înghețare.

3. Capturează baza de referință semnată. Ce: păstrează înainte de lansare sesiunile organice, clickurile, impresiile, conversiile, veniturile, URL-urile indexate, erorile de accesare, codurile de răspuns, uptime-ul și performanța pentru șabloanele și directoarele prioritare. De ce: fără un punct de comparație datat, variația normală și daunele migrării arată la fel. Cum: exportă cel puțin 28 de zile comparabile, adnotează campaniile și sezonalitatea și identifică URL-urile prioritare care necesită revizuire zilnică. Instrument: analytics, Search Console, crawler, date de poziționare și monitorizare. Finalizat când: baza de referință este read-only, reproductibilă, segmentată, marcată temporal și aprobată de proprietarii SEO și analytics.

Faza 2: maparea redirecționărilor

4. Mapează sursele unu-la-unu acolo unde este posibil. Ce: atribuie fiecare URL vechi mutat sau comasat celui mai apropiat URL nou cu aceeași intenție principală. De ce: o destinație precisă păstrează continuitatea pentru vizitator și oferă crawlerilor un semnal de înlocuire coerent. Cum: compară subiectul, produsul, geografia, limba și sarcina; mapează comasările către pagina supraviețuitoare și documentează eliminările deliberate. Nu mapa niciodată URL-uri nepotrivite către pagina principală. Instrument: foaie de calcul hartă redirecționări, inventar și accesare destinații. Finalizat când: fiecare sursă care se schimbă are exact un rezultat aprobat, fiecare destinație este relevantă și în sfera de aplicare, iar mapările universale către pagina principală sunt zero.

5. Validează mecanica redirecționărilor înainte de lansare. Ce: testează codurile de stare, destinațiile, comportamentul cu parametrii, variantele de majuscule, protocolul, subdomeniile, slash-urile finale, fișierele și URL-urile de campanie. De ce: o foaie de calcul corectă ca aspect poate produce bucle, lanțuri, wildcarduri care înghit pagini valide sau destinații care returnează erori. Cum: generează regulile de staging sau proxy, solicită fiecare sursă, urmărește salturile și compară URL-ul final cu harta aprobată. Instrument: test HTTP automatizat, crawler și revizuire a configurației serverului. Finalizat când: 100% dintre sursele mapate ajung la destinația 200 aprobată într-un singur salt de redirecționare permanentă; buclele, lanțurile, redirecționările temporare și destinațiile cu erori sunt zero.

6. Reconciliază canonicalele, linkurile și sitemapurile cu redirecționările. Ce: asigură-te că URL-ul canonic , linkurile interne, referințele hreflang, datele structurate, feedurile și sitemapurile XML indică direct către URL-urile finale. De ce: redirecționarea URL-urilor vechi în timp ce continui să le publici creează semnale de migrare conflictuale și irosește solicitările crawlerilor. Cum: accesează fiecare sursă de referință și compară țintele normalizate cu harta de redirecționări. Instrument: crawler, HTML randat, parser de sitemap și comparație de configurații. Finalizat când: paginile finale se auto-canonicalizează cu excepția cazului în care o excepție aprobată spune altceva, referințele interne către URL-uri redirecționate sunt zero, iar sitemapurile noi conțin doar URL-uri canonice 200.

Faza 3: validarea în staging

7. Testează staging-ul fără a-l face indexabil public. Ce: accesează lansarea completă în staging împiedicând în același timp motoarele de căutare să indexeze mediul. De ce: echipa are nevoie de dovezi la nivel de crawler fără a permite un site duplicat în rezultatele căutării. Cum: folosește controlul accesului pentru crawlerii externi, apoi rulează o accesare internă autentificată cu randare JavaScript acolo unde site-ul de producție depinde de aceasta. Tratează un blocaj de staging ca o configurație temporară de lansare, nu ceva de copiat orbeste în producție. Instrument: crawler autentificat, browser și inspectare a antetelor de răspuns. Finalizat când: inventarul așteptat de staging poate fi accesat de echipa de testare, indexarea publică neautorizată este blocată, iar checklist-ul de lansare în producție elimină explicit controalele specifice staging-ului.

8. Verifică șabloanele și drumurile prioritare. Ce: testează pagini reprezentative din fiecare șablon, plus navigația, căutarea, formularele, înregistrarea, finalizarea comenzii, localizarea, paginarea, filtrele și paginile de eroare. De ce: o promovare a paginii principale nu poate dezvălui o eroare de canonical pe paginile de produs sau o stare de consimțământ întreruptă care suprimă analytics. Cum: creează o matrice dispozitiv-și-șablon, testează sesiuni curate și care revin și înregistrează capturi de ecran sau dovezi de răspuns pentru fiecare rezultat. Instrument: browser, verificator de accesibilitate, validator de date structurate, depanator analytics și teste de tranzacții. Finalizat când: fiecare șablon și drum principal din sfera de aplicare promovează pe browserele și dispozitivele convenite, fără defecte critice deschise.

9. Compară staging-ul cu contractele aprobate. Ce: diferențiază titlurile, descrierile, anteturile, canonicalele, directivele robots, datele structurate, linkurile interne, codurile de răspuns, conținutul și etichetele analytics față de site-ul vechi și specificația destinației. De ce: migrările de platformă pierd adesea metadate sau modifică randarea chiar și atunci când copia vizibilă pare intactă. Cum: accesează producția veche și staging-ul cu setări potrivite, segmentează diferențele pe șablon și aprobă doar modificările intenționate. Instrument: raport de diferențiere a accesărilor și inspectare a sursei. Finalizat când: fiecare diferență materială este fie corectată, fie listată ca modificare aprobată cu proprietar și motiv; modificările accidentale de noindex, canonical, conținut și urmărire sunt zero.

10. Îngheață candidatul de lansare. Ce: îngheață inventarul de URL-uri, harta de redirecționări, definițiile rutelor, regulile canonice și robots, generarea sitemapurilor, configurația de analytics și consimțământ, planul DNS/CDN și implementările de producție nelegate. De ce: un rezultat de test se aplică doar versiunii testate. Cum: etichetează artefactele de lansare, restricționează modificările la calea de incident și solicită retestarea a orice afectat de o editare de urgență. Instrument: sistem de implementare, jurnal de modificări și înregistrare de aprobare. Finalizat când: un candidat imuabil este numit, accesul este restricționat, toate excepțiile au un proprietar și fiecare modificare post-înghețare are un rezultat de test.

Faza 4: ziua lansării

11. Execută un singur runbook deținut. Ce: implementează rutarea, aplicația, DNS/CDN, analytics, sitemapurile și monitorizările în ordinea aprobată. De ce: schimbările paralele nesecvențiate fac defectele greu de izolat și revenirea nesigură. Cum: un singur lider de migrare cheamă fiecare pas, operatorul desemnat înregistrează finalizarea, iar validatorii testează dovezile înaintea următorului pas dependent. Instrument: runbook, loguri de implementare, verificări DNS și canal partajat de incidente. Finalizat când: fiecare linie are o oră efectivă, operator, rezultat și link cu dovezi și nicio dependență nu este marcată completată doar pe baza asigurării verbale.

12. Rulează testul fum de lansare. Ce: testează pagina principală, fișierul robots, sitemapurile, cel puțin un URL pe șablon, fiecare drum principal, primirea analytics și un eșantion stratificat de surse de redirecționare. De ce: cel mai rapid răspuns sigur vine din detectarea unui eșec larg înainte ca cache-urile și crawlerii să îl răspândească. Cum: testează din afara rețelei de producție, folosește desktop și mobil, verifică atât HTML-ul livrat de server, cât și rezultatul randat și compară cu așteptările înghețate. Instrument: crawler, browser, client HTTP, vizualizare în timp real analytics și monitor de tranzacții. Finalizat când: paginile critice returnează starea și conținutul intenționat, redirecționările prioritare ajung la destinațiile lor exacte, evenimentele de analytics sosesc cu URL-uri corecte și toate verificările care blochează lansarea sunt promovate.

13. Trimite și verifică semnalele de descoperire. Ce: publică sitemapurile finale, confirmă comportamentul robots și canonical și solicită inspectarea pentru un set mic de URL-uri prioritare. De ce: semnalele de descoperire curate ajută crawlerii să întâlnească setul de destinații fără a trata trimiterea ca pe o garanție de indexare. Cum: trimite fiecare sitemap de producție o singură dată, inspectează URL-uri noi reprezentative și înregistrează canonicalul raportat de Google și starea de indexare. Instrument: Sitemapuri și Indexare și Inspectare URL . Finalizat când: sitemapurile sunt accesibile și conțin inventarul canonic înghețat, inspecțiile reprezentative nu arată niciun blocaj de producție sau canonical greșit și fiecare avertisment are un proprietar.

Faza 5: monitorizare post-lansare

14. Urmărește primele 72 de ore ca fereastră de incident. Ce: monitorizează continuu sau la cel mai scurt interval practic uptime-ul, 5xx, 4xx, eșecurile de redirecționare, latența, volumul de accesări, primirea analytics, conversiile, procesarea sitemapurilor și drumurile prioritare. De ce: defectele de infrastructură și rutare ies la suprafață rapid, în timp ce performanța în căutări durează mai mult și nu ar trebui folosită ca singură alarmă de lansare. Cum: compară cu baza de referință semnată, segmentează pe șablon și director și direcționează alertele către un proprietar de gardă. Instrument: loguri, analytics, crawler, Monitorizare Uptime și dashboard de incidente. Finalizat când: dashboard-ul nu are nicio alertă critică de lansare neexplicată, fiecare incident are un proprietar și marcaj temporal, iar evaluările la 24, 48 și 72 de ore sunt semnate.

15. Continuă monitorizarea căutării și indexării după stabilizare. Ce: urmărește clickurile, impresiile, starea de indexare, canonicalele selectate, erorile de accesare, performanța pe directoare și rezultatele conversiilor la nivel de pagină timp de cel puțin patru săptămâni. De ce: accesarea, selecția canonicală și înlocuirea indexului rămân în urma validării infrastructurii. Cum: compară ferestre similare, separă URL-urile mutate de controalele neschimbate și investighează clustere, nu reacționa la totalul unei singure zile. Instrument: Pagini Google Search , Vizualizare director , Inspectare URL, analytics și loguri. Finalizat când: destinațiile prioritare sunt descoperibile și indexabile, URL-urile vechi se rezolvă consecvent către destinațiile aprobate, pierderile neexplicate au tickete, iar responsabilitatea trece în cadența normală de raportare.

Instrumente în AmICited

AmICited oferă dovezi de lansare și suprafețe de monitorizare; harta de redirecționări aprobată și logurile de implementare rămân sursa operațională de adevăr.

Reguli de decizie

Acestea sunt bariere de protecție ale lansării, nu praguri universale ale motoarelor de căutare. Conveniți-le înainte de lansare și înăspriți-le acolo unde riscul o cere.

Revenirea restaurează o stare de serviciu cunoscută ca fiind bună; nu inversează fluctuațiile obișnuite ale căutării. Autoritatea de lansare aplică regulile convenite și înregistrează dovezile.

Livrabil

Predă un pachet versionat de control al migrării, accesibil ingineriei și SEO. Folosește o foaie de calcul sau o bază de date pentru înregistrări la nivel de rând, un runbook pentru acțiunile de lansare și un dashboard pentru măsurători live.

Trebuie să conțină inventarul înghețat și reconcilierea surselor; harta de redirecționări aprobată cu proprietari și teste; accesări potrivite vechi, staging și noi; diferențe de metadate, canonical, robots, sitemap, hreflang, date structurate, linkuri și analytics; baza de referință semnată și cohortele prioritare; runbook de lansare și procedură de recuperare; reguli numerice de revenire și proprietarul deciziei; și dovezile la 24, 48 și 72 de ore cu responsabilitatea de monitorizare pe patru săptămâni.

Liderul de migrare trebuie să poată identifica lansarea exactă, să demonstreze fiecare test critic, să reconstruiască fiecare decizie de rutare și să atribuie fiecare excepție. Altfel, pachetul este incomplet.

Ce merge prost

Harta de redirecționări folosește doar sitemapul curent. URL-urile orfane, cele de campanie, backlinkurile și rutele indexate anterior dispar, așa că fiecare rând din foaia de calcul promovează în timp ce solicitările reale eșuează.

Pagina principală devine destinația implicită. Utilizatorii ajung undeva irelevant, semnalele crawlerilor devin ambigue, iar conținutul lipsă este mascat drept progres al implementării.

Redirecționările funcționează, dar referințele rămân vechi. Navigația, hreflang, canonicalele, datele structurate și sitemapurile continuă să trimită crawlerii prin salturi inutile și destinații conflictuale.

Protecția staging-ului ajunge în producție. Un noindex copiat, o regulă de autentificare, un blocaj robots sau o politică CDN distruge indexabilitatea . Solicită un pas explicit de eliminare și un test extern.

Echipa validează doar pagina principală. Un șablon partajat poate configura greșit mii de pagini în timp ce pagina principală promovează. Eșantionează fiecare șablon și accesează regulile la scară.

Lansările nelegate sunt livrate împreună. Când platforma, analytics, consimțământul, navigația, finalizarea comenzii și modificările CDN împart aceeași fereastră, eșecurile devin greu de izolat sau de inversat.

Căutarea este judecată prea devreme sau prea larg. Totalurile site-ului ascund directoarele întrerupte și o singură zi volatilă provoacă remedieri inutile. Compară cohortele mutate, controalele neschimbate, directoarele și ferestrele potrivite.

Revenirea este dezbătută în timpul întreruperii. Un plan bun numește praguri, decident, timp de recuperare, comenzi, consecințe asupra datelor și secvența de validare înainte de lansare.

Faza următoare

Odată ce primele 72 de ore sunt stabile, următorul pas este reîmprospătarea și iterația continuă . Are nevoie de baza de referință semnată, maparea finală a URL-urilor, adnotările de lansare, cohortele pe directoare, excepțiile cunoscute, istoricul incidentelor și proprietarii numiți din acest checklist. Fără aceste intrări, o pierdere ulterioară de trafic nu poate fi separată fiabil între daune de migrare, schimbare obișnuită a cererii, degradare a conținutului sau eșec de măsurare.

Păstrează harta de redirecționări și adnotările migrării permanent. Mută constatările necritice în cadența normală de raportare cu o severitate, ipoteză, proprietar, termen limită și metodă de verificare.

Întrebări frecvente

Când ar trebui să se alăture echipa SEO unei migrări de site?

Înainte ca rutele, șabloanele și constrângerile platformei să fie fixate. SEO are nevoie de suficient timp pentru a inventaria URL-urile curente, a păstra destinațiile valoroase, a influența noua arhitectură informațională, a defini comportamentul redirecționărilor și a conveni reguli măsurabile de lansare și revenire.

Ar trebui URL-urile vechi să redirecționeze către pagina principală atunci când nu există un înlocuitor direct?

Nu. Redirecționează un URL vechi către cea mai apropiată pagină care satisface aceeași intenție a utilizatorului. Dacă nu există nicio destinație relevantă și conținutul nu trebuie păstrat, returnează un cod 404 sau 410 corect, în loc să trimiți utilizatorii și crawlerii către o pagină principală nelegată de subiect.

Cât timp ar trebui să rămână active redirecționările de migrare?

Menține redirecționările permanente atâta timp cât URL-urile vechi pot primi în continuare vizite, linkuri, marcaje sau solicitări de la crawleri. Tratează-le ca infrastructură de rutare durabilă, nu ca schele de lansare de îndepărtat după câteva săptămâni.

Ce ar trebui înghețat înainte de lansarea migrării?

Îngheață inventarul de URL-uri aprobat, harta de redirecționări, regulile canonice și robots, generarea sitemapurilor, configurația de analytics și consimțământ, modificările DNS și CDN și lansările de producție nelegate. Remedierile de urgență urmează calea numită de control al schimbărilor.

Când ar trebui revenită o migrare?

Folosește criterii convenite înainte de lansare. Revino pentru eșecuri precum indisponibilitate prelungită, răspunsuri 5xx generalizate, drumuri primare întrerupte, analytics lipsă sau defecte de rutare care afectează o parte semnificativă a URL-urilor prioritare și care nu pot fi corectate în siguranță în fereastra de recuperare convenită.