Rețetă pentru harta de redirecționare: clasarea URL-urilor vechi în funcție de link-urile pe care le dețin
O hartă de redirecționare este o listă de priorități, nu un spreadsheet cu fiecare URL. Începe cu paginile către care linkuiesc alte site-uri, iar restul hărții devine mai ușor de gestionat.
Echipa de cercetare ArchiLinks ·

De ce să clasezi în funcție de link-uri
Echipele construiesc hărți pe baza crawl-ului. Este complet. Totuși, tratează o pagină de presă uitată din 2014 ca pe pagina principală.
Când verifici backlink-urile către site-ul tău și sortezi paginile în funcție de numărul de domenii care linkuiesc, apare un tipar în majoritatea migrărilor: câteva zeci de URL-uri dețin cea mai mare parte din valoarea externă. Aceste URL-uri se potrivesc manual, sunt revizuite de două ori și testate primele.
Restul urmează reguli. Folderele se mapează prin pattern-uri, parametrii sunt eliminați, iar URL-urile orfane fără link-uri și fără trafic pot returna 410 dacă decizi așa. Asociază rezultatul cu lista de verificare pentru migrare astfel încât harta să fie testată înainte de lansare și re-verificată în ziua 45, și cu scripturile API pentru programarea extragerii lunare.
Pasul 1: extrage paginile linkuite
Un singur apel returnează până la 1.000 de rânduri și costă 2 credite, indiferent de numărul de rânduri. Numele câmpurilor de mai jos sunt un exemplu; verifică un răspuns real și ajustează cheile.
import csv, requests
BASE = "https://archilinks.com/api.php"
KEY = "sk_live_..."
def call(action, **params):
r = requests.get(BASE, params={"action": action, "key": KEY, **params}, timeout=30)
r.raise_for_status()
return r.json()
data = call("toppages", q="old-shop.com", per=1000)
rows = next(v for v in data.values() if isinstance(v, list))
with open("linked-pages.csv", "w", newline="") as f:
w = csv.writer(f)
w.writerow(["old_url", "links", "new_url"])
for row in rows:
w.writerow([row.get("url"), row.get("backlinks"), ""])Pasul 2: completează a treia coloană
Potrivește prin semnificație
O pagină de produs merge la același produs, sau la categoria sa dacă produsul a dispărut. Nu la pagina principală, decât dacă pagina respectivă a fost pagina principală.
Lasă o a doua persoană să verifice primele 50
O persoană obosită la ora 18:00 mapază un ghid despre canonical la indexul blogului. Un revizor prinde greșeala.
Reguli pentru coada lungă
Scrie pattern-uri pentru foldere și elimină parametrii de tracking. Păstrează fiecare regulă în controlul versiunilor cu un comentariu care explică de ce.
Pasul 3: generează regulile serverului
nginx citește bine un fișier map, iar acesta scalează la zeci de mii de linii.
# /etc/nginx/redirects.map (generated from the csv)
/old/guide-canonicals /guides/canonical-tags;
/products/blue-widget /shop/widgets/blue;
# in nginx.conf, http context
map $request_uri $new_uri {
default "";
include /etc/nginx/redirects.map;
}
# in the server block of the old host
if ($new_uri) {
return 301 https://new-shop.com$new_uri;
}
Pasul 4: testează fiecare salt
Eșuează pipeline-ul pentru orice nu este un 301 unic către un 200.
while IFS=, read -r old new; do
out=$(curl -s -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}" -L "https://old-shop.com$old")
echo "$old -> $out"
done < redirect-pairs.csv | grep -v "^.* -> 200 1 " && echo "FIX ABOVE"Greșeli pe care am verifica mai întâi
| Simptom | Cauză probabilă | Rezolvare |
|---|---|---|
| Lanțuri de două sau trei salturi | Reguli vechi suprapuse peste cele noi | Indică regula veche direct către URL-ul final |
| Totul aterizează pe pagina principală | Regula catch-all leneșă | Potrivește pe bază de subiect; Google poate trata redirecționările masive către pagina principală ca pe soft 404-uri |
| Șirurile de interogare (query strings) se pierd | Regula elimină argumentele | Păstrează parametrii care modifică conținutul; elimină restul |
| URL-ul principal returnează 404 după lansare | Exclus din CSV | Rulează din nou extragerea și compară cu harta live |

Care URL-uri merită un rând mapat manual
Nu fiecare URL merită o persoană. O împărțire utilă este în funcție de domeniile care linkuiesc: orice URL cu mai multe site-uri externe care linkuiesc către el se potrivește manual, iar restul urmează un set de reguli. Să zicem că ai 4.000 de URL-uri vechi și 60 dintre ele dețin majoritatea link-urilor externe. Acele șaizeci necesită o după-amiază de revizuire, în timp ce celelalte 3.940 necesită un pattern și un test.
Păstrează pragul în script, nu în mintea cuiva. Cinci domenii care linkuiesc este un început rezonabil pentru un site mediu. Începe de acolo. Scade numărul când întregul site are puține link-uri și crește-l când lista manuală devine prea lungă pentru un singur revizor.
Menținerea rândurilor mapate manual și mapate prin reguli separate
Rândurile mapate manual au un revizor numit și o notă despre de ce a fost ales ținta. Rândurile mapate prin reguli au un pattern testat pe întregul folder, astfel încât o excepție să apară în raportul de test înainte de lansare, nu într-un grafic de trafic ulterior.
Cazurile mixte cauzează cea mai multă confuzie. Un produs care a fost discontinuat și înlocuit cu un succesor se mapază la succesor. Unul discontinuat fără succesor aparține categoriei sale, niciodată paginii principale.
Folosirea unei a doua extrageri pentru a vedea ce s-a mutat
Rulează refdomains pentru gazda veche înainte ca harta să fie finală, apoi din nou după lansare, și potrivește cele două liste pe domeniu. Un domeniu care linkuiește lipsit din a doua extragere este o întrebare pentru proprietarul link-ului, nu un motiv de alarmă, deoarece un link eliminat poate dura ceva timp până apare în index.
Păstrează ambele fișiere alături în folderul de migrare, cu data în fiecare nume. Diff-ul îți spune unde să te uiți, iar harta îți spune ce ai făcut în legătură cu asta.
Deciderea ce se face cu URL-urile care nu au link-uri
URL-urile orfane fără link-uri și fără trafic sunt partea ușoară. Returnează un 404 clar sau un 410 când conținutul a dispărut definitiv, și redirecționează doar când există un înlocuitor apropiat, astfel încât vizitatorii și crawlerii să ajungă undeva util.
Când ești nesigur, lasă o notă scurtă în hartă și revino după prima săptămână de logs. Log-ul serverului tău arată care adrese vechi primesc încă cereri, ceea ce este cea mai bună dovadă pe care o vei avea.
Cum se încadrează harta într-un release
O hartă de redirecționare se schimbă odată cu site-ul. Ține acest lucru în minte. Apar pagini noi, altele sunt redenumite, iar o modificare de template poate strica o regulă care părea sigură luna trecută. Tratează harta ca pe un cod, cu un singur fișier în controlul versiunilor, o revizuire înainte de fiecare deploy și un test pe fiecare modificare.
Păstrează harta într-un singur strat pe cât posibil. Redirecționările răspândite în aplicație, CDN și CMS sunt cum apar lanțurile, iar lanțurile sunt greu de detectat fără un crawl complet.
Unde ar trebui să trăiască regulile
O hartă server este rapidă și ușor de testat. Un plugin CMS este util pentru câteva pagini, dar este greu de auditat la scară mare. Indiferent ce alegi, testul la un singur salt trebuie să citească din același loc.
Dacă două straturi redirecționează același URL, testul raportează un lanț. Elimină duplicatul din stratul pe care intenționezi să îl retragi.
Testarea pe gazda reală după fiecare modificare
Rulează testul de salt pe staging, apoi pe production, după fiecare modificare a fișierului de reguli. O regulă care trece pe staging poate eșua odată ce un cache deține un răspuns vechi, astfel încât a doua rulare contează.
Salvează output-ul cu data. Când un URL principal se strică luni mai târziu, rezultatul vechi arată dacă regula s-a schimbat sau site-ul. Lista de verificare pentru migrare listează când aparține acel test, iar rularea lui prima dată menține următorul test comparabil cu acesta.
Revizuirea unei modificări a fișierului de reguli
Numără un singur revizor pentru modificările hărții și cere acelei persoane să verifice trei lucruri: dacă fiecare țintă se potrivește încă cu subiectul, câte salturi creează regula și dacă pattern-ul este suficient de îngust pentru a atinge doar URL-urile pentru care a fost scris. O modificare pe care nimeni nu a revizuit-o este cea mai probabilă să înceapă un lanț.
Cere aceeași revizuire când site-ul însuși se schimbă. O categorie nouă care absoarbe un folder vechi poate face ca o regulă corectă să indice spre locul greșit fără ca cineva să editeze harta.
Stoacă nota revizorului lângă modificare. După șase luni, nota explică o regulă care altfel ar părea arbitrară și salvează o a doua investigație a aceleiași întrebări.
Testarea unui eșantion înainte de rularea completă
Înainte să rulezi întreaga listă, alege un eșantion de cincizeci de rânduri care combină paginile cele mai linkuite cu câteva obișnuite. Rulează testul de salt pe acel eșantion mai întâi. Eșantionul este rapid de citit, iar o eroare de regulă apare în el mult înainte să apară pe fișierul întreg.
Include cel puțin un rând din fiecare pattern de regulă și unul din fiecare grup mapat manual. Un pattern care acoperă un folder de două sute de URL-uri este testat doar de rândurile care întâmplător sunt în eșantion, așa că alege-le intenționat.
Menținerea fișierelor de reguli mici
Un fișier de reguli care crește peste câteva sute de pattern-uri devine greu de revizuit. Împarte-l pe secțiuni ale site-ului și păstrează fiecare fișier suficient de scurt pentru ca un revizor să îl poată citi într-o singură ședință.
Elimină o regulă în ziua în care folderul său a dispărut. Regulile vechi lăsate în urmă sunt cele care trimit ulterior traficul într-un lanț.
Înainte ca harta să meargă live
- Fiecare rând are un URL nou, sau un 404 sau 410 deliberat.
- Nicio țintă nu este ea însăși un redirecționare.
- Cele 50 de URL-uri cu cele mai multe domenii care linkuiesc au fost revizuite de o a doua persoană.
- Parametrii de interogare care modifică conținutul sunt păstrați.
- Fișierul de reguli este în controlul versiunilor, cu un comentariu pe fiecare pattern.
- O bază de date a domeniilor de referință este salvată pentru diff-ul post-lansare.
Întrebări frecvente despre redirecționare
- Ar trebui să elimin redirecționările vechi după un an?
- Multe echipe de migrare le păstrează cel puțin un an. Dincolo de asta, păstrează-le atâta timp cât URL-urile vechi primesc încă link-uri externe sau trafic. Redirecționările costă aproape zero să fie servite, astfel că rar există un motiv bun să le ștergi devreme.
- Este ok să redirecționez doar paginile indexate?
- Nu dacă cele neindexate au link-uri. Starea de indexare spune puțin despre valoarea externă. Redirecționează fiecare URL care are un domeniu care linkuiește, apoi decide pe restul în funcție de trafic.
- Ce zici de 302 sau 307 pentru o mutare permanentă?
- Folosește 301 sau 308 pentru mutări permanente. Un 302 lăsat în loc pentru ani poate fi tratat ca unul permanent, dar acel rezultat este lăsat la voia întâmplării, iar alți clienți ai redirecționării pot să nu ghicească la fel.
- Pot redirecționa 404-urile de pe site-ul vechi către noul site?
- Doar când există o potrivire apropiată. Un redirecționare către o pagină neînrudită este un soft 404 în ochii Google. Returnează un 404 sau 410 real când conținutul a dispărut.