Audit tehnic de bază

Faza P2 · Etapa A — Înțelegere
Timp alocat: 2–4 ore pentru o trecere ușoară, 1–2 zile lucrătoare pentru o trecere standard, sau 3–8 zile lucrătoare pentru o trecere aprofundată.
Responsabil: liderul SEO tehnic. Ingineria, analiza, conținutul și localizarea contribuie cu dovezi și acceptă corectări în domeniile lor.

Un audit tehnic de bază stabilește dacă motoarele de căutare pot ajunge la, pot interpreta și pot selecta URL-urile pe care afacerea se așteaptă să le afișeze. Domeniul său acoperă controalele de crawl, răspunsurile HTTP, indexarea, canonicii, legăturile, randarea, direcționarea internațională și livrarea securizată. Rezultatul este un registru prioritizat de constatări cu responsabili numiți și teste de acceptare, nu un scor.

De ce această fază vine aici

Publicarea pe un site cu probleme de crawl sau indexare amplifică daunele. Motoarele de căutare descoperă adesea un defect repetat pe noile URL-uri mai repede decât evaluează și recompensează conținutul. Un șablon canonic greșit poate trimite fiecare articol în altă parte; o regulă robots poate ascunde un director; navigația randată pe client poate crea orfani pentru un client non-JavaScript. Fiecare pagină nouă mărește setul afectat și face repararea mai riscantă.

Corectează mai întâi fundația. Ordinea este capacitatea de crawl → capacitatea de indexare → calitatea conținutului → performanță, deoarece fiecare strat este o poartă. Capacitatea de crawl înseamnă că un crawler poate descoperi și solicita un URL; capacitatea de indexare înseamnă că URL-ul accesibil este eligibil pentru includere. Abia apoi ar trebui judecate calitatea conținutului și performanța. O pagină rapidă blocată de robots.txt nu poate concura, iar tag-urile de titlu nu contează pe paginile inaccesibile.

Această fază consumă domeniul, călătoriile prioritare, piețele și riscurile din Descoperire și obiective . Efectuarea ei mai devreme produce un crawl fără context de afaceri. Omiterea ei lasă cercetarea și producția să vizeze șabloane care nu pot intra în mod fiabil în index.

Intrări și ieșiri

Intrările definesc site-ul intenționat, nu doar ceea ce găsește un crawler. Ieșirile îi spun următorului responsabil care URL-uri sunt sigure de testat și care rămân blocate.

Alege profunzimea auditului

Selectează profunzimea înainte de crawl. Estimările presupun că accesul este pregătit și exclud implementarea.

Lista de verificare

Lucrează în ordine. O poartă eșuată poate invalida mostrele ulterioare, așa că înregistrează eșecul și domeniul său înainte de a continua.

1. Confirmă că ținta este producția

Ce trebuie făcut: verifică schema, host-ul, fișierul robots, proprietatea de analiză, proprietatea Search Console și host-ul sitemap-ului. De ce contează: mediul de staging poate părea curat în timp ce producția rămâne defectă. Cum se face: rezolvă host-ul canonic agreat, compară paginile prioritare și anteturile de răspuns și înregistrează originea crawl-ului. Instrument: browser, configurare crawler, selector Search Console. Finalizat când: registrul numește originea și proprietatea de producție confirmate, fără hostname de staging în semințe sau exporturi.

2. Testează robots.txt înainte de crawl

Ce trebuie făcut: inspectează /robots.txt al fiecărui host de producție și sitemap-urile referențiate. De ce contează: o regulă Disallow împiedică accesul prin crawl înainte ca conținutul să poată fi evaluat. Cum se face: compară tiparele Disallow cu inventarul intenționat, testează URL-urile care se potrivesc și cele care nu se potrivesc și diferențiază un blocaj de crawl de noindex. Instrument: răspuns brut și tester robots. Finalizat când: robots returnează 200, blocajele intenționate au motive, mostrele indexabile sunt permise și un blocaj neintenționat declanșează o constatare critică.

3. Reconcilierea sitemap-urilor cu URL-urile reale

Ce trebuie făcut: compară sitemap-urile trimise cu inventarul canonic, indexabil. De ce contează: un sitemap ar trebui să numească URL-urile pe care site-ul dorește să le selecteze, nu redirecționări, erori sau duplicate. Cum se face: normalizează intrările, compară numărătorile pe șablon, apoi eșantionează adăugările și omisiunile în Sitemap-uri și Indexare . Instrument: https://app.amicited.com/reports/google-search/sitemaps-indexing și exporturi crawl. Finalizat când: acoperirea este de cel puțin 95%, 0 intrări redirecționează sau au erori și fiecare lacună are un motiv sau un responsabil.

4. Măsoară distribuția codurilor de stare

Ce trebuie făcut: clasifică răspunsurile ca 2xx, 3xx, 4xx sau 5xx. De ce contează: erorile opresc preluarea, iar redirecționările adaugă salturi. Cum se face: urmărește și raportează redirecționările, segmentează pe șablon și compară cu Crawl Bing . Instrument: https://app.amicited.com/reports/bing-webmasters/crawl, crawler și monitorizare. Finalizat când: URL-urile indexabile returnează 200; erorile interne, buclele și lanțurile sunt zero; iar redirecționările intenționate sunt documentate.

5. Elimină lanțurile și buclele de redirecționare

Ce trebuie făcut: urmărește redirecționările până la răspunsul lor final. De ce contează: salturile încetinesc descoperirea; o buclă nu ajunge niciodată la conținut. Cum se face: exportă căi, actualizează legăturile interne către canonicii finali și consolidează regulile. Instrument: raport de redirecționări și verificări de antet. Finalizat când: legăturile interne merg direct, redirecționările moștenite fac un singur salt și nu rămâne nicio buclă sau lanț.

6. Stabilește raportul de indexare eligibil

Ce trebuie făcut: compară starea indexului Google cu URL-urile deliberate eligibile. De ce contează: includerea redirecționărilor, filtrelor, duplicatelor sau paginilor noindex face raportul lipsit de sens. Cum se face: construiește numitorul eligibil, inspectează mostrele prioritare în Inspecție URL , și grupează excluderile pe șablon. Instrument: https://app.amicited.com/reports/google-search/url-inspection, Search Console și inventar. Finalizat când: cel puțin 90% sunt indexate sau fiecare lacună are un responsabil de cauză principală; sub 80% este o constatare majoră.

7. Verifică corectitudinea canonică

Ce trebuie făcut: compară canonicii declarați, finali și selectați de Google. Un canonic este versiunea preferată dintre URL-urile similare. De ce contează: un canonic greșit consolidează semnalele departe de pagina intenționată. Cum se face: testează autoreferințele paginilor unice, canonicii încrucișați deliberați și consistența între HTML, sitemap-uri, redirecționări și legături. Instrument: raport de canonic și https://app.amicited.com/reports/google-search/url-inspection. Finalizat când: 100% dintre paginile indexabile unice numesc un canonic absolut, 200, indexabil, cu fiecare nepotrivire selectată explicată.

8. Găsește grupuri de duplicate și aproape-duplicate

Ce trebuie făcut: grupează URL-urile cu conținut principal identic sau substanțial suprapus și același scop de căutare. De ce contează: duplicatele divid semnalele interne și forțează motoarele de căutare să aleagă o versiune pe care afacerea poate să nu o prefere. Cum se face: compară hash-uri exacte, similaritatea textului normalizat, titluri, canonic, parametri și scopul șablonului; apoi alege consolidarea, diferențierea, noindex sau eliminarea. Instrument: rapoarte de duplicate ale crawler-ului, inventar de pagini și Pagini Google Search . Finalizat când: niciun grup nu conține mai mult de un URL canonic indexabil neexplicat care servește aceeași intenție și fiecare variantă acceptată are un scop distinct înregistrat.

9. Găsește orfani și măsoară adâncimea legăturilor

Ce trebuie făcut: îmbină URL-urile crawler-ului cu sitemap-uri, analize, Search Console, exporturi CMS și backlink-uri pentru a găsi pagini fără o legătură internă accesibilă prin crawl. Măsoară cea mai scurtă cale de clic de la pagina principală. De ce contează: un orfan poate apărea într-un sitemap, dar poate primi puțin context intern sau autoritate; adâncimea excesivă face descoperirea fragilă. Cum se face: compară sursele, inspectează tiparele de directoare în Vizualizare Director , și urmărește navigația, firimiturile de pâine, hub-urile și legăturile contextuale. Instrument: https://app.amicited.com/reports/directory și un crawl multi-sursă. Finalizat când: numărul intenționat de orfani este zero, paginile prioritare sunt la maximum trei clicuri de pagina principală, celelalte pagini indexabile intenționate sunt la maximum cinci clicuri, iar fiecare excepție are o rută de descoperire deliberată.

10. Compară HTML-ul randat și cel non-JavaScript

Ce trebuie făcut: compară răspunsul inițial al serverului cu pagina după execuția JavaScript. De ce contează: un browser poate afișa conținut și legături pe care un client non-JavaScript nu le primește niciodată. Cum se face: preia pagini reprezentative cu scripturile dezactivate, inspectează HTML-ul brut, apoi compară titlurile, textul principal, legăturile, canonicul, directivele robots, datele structurate și starea după randare. Instrument: crawler în modurile HTML și randat, plus instrumente de dezvoltator ale browserului. Finalizat când: răspunsul inițial conține conținutul principal, canonicul, directivele de index și navigația accesibilă prin crawl necesare pentru a descoperi paginile prioritare; orice dependență exclusiv JavaScript este acceptată în mod explicit și testată pe toate șabloanele.

11. Validează hreflang acolo unde este cazul

Ce trebuie făcut: verifică adnotările care conectează echivalente lingvistice sau regionale. De ce contează: grupuri incomplete sau conflictuale pot face ca motoarele de căutare să ignore direcționarea și să afișeze versiunea greșită pentru piață. Cum se face: testează codurile limbă-regiune valide, URL-urile canonice absolute, autoreferințele, legăturile reciproce de întoarcere, x-default acolo unde are un rol real de rezervă și indexabilitatea fiecărei ținte. Instrument: raport hreflang al crawler-ului și mostre URL. Finalizat când: codurile invalide, autoreferințele lipsă, întoarcerile lipsă, țintele non-canonice, redirecționările și erorile sunt toate zero. Dacă site-ul nu are echivalente localizate, înregistrează „nu se aplică" în loc să inventezi adnotări.

12. Testează paginarea și căile de crawl

Ce trebuie făcut: verifică dacă secvențele de categorii sau arhive multi-pagină expun legături accesibile prin crawl și URL-uri unice utile. De ce contează: derularea infinită sau încărcarea doar pe buton poate ascunde elemente mai adânci, în timp ce canonicalizarea fiecărei pagini la pagina unu poate elimina inventarul distinct din descoperire. Cum se face: dezactivează JavaScript, urmărește legăturile următoare și numerotate, inspectează starea, directivele canonice și robots și testează ultima pagină și parametrii în afara intervalului. Instrument: crawl nerandat și browser. Finalizat când: fiecare element intenționat este accesibil prin legături ancora, fiecare pagină utilă se auto-canonicalizează, numerele de pagină invalide returnează o eroare adecvată în loc de un 200 fals și nicio secvență nu creează un spațiu URL nelimitat.

13. Verifică paritatea mobilă

Ce trebuie făcut: compară livrarea mobilă și desktop pentru conținut, legături, metadate, directive, date structurate și starea răspunsului. De ce contează: Google evaluează în primul rând reprezentarea mobilă; ascunderea conținutului sau legăturilor semnificative doar pe mobil schimbă ceea ce poate înțelege. Cum se face: crawl cu agenți utilizator desktop și smartphone și compară șabloane reprezentative, nu doar capturi de ecran vizuale. Instrument: crawl-uri pereche, inspecție URL mobilă și modul responsive al browserului. Finalizat când: tot conținutul indexabil și legăturile accesibile prin crawl necesare pentru sens și descoperire sunt echivalente, cu zero blocaje doar pe mobil, diferențe canonice sau răspunsuri de eroare.

14. Impune HTTPS și elimină conținutul mixt

Ce trebuie făcut: verifică livrarea securizată, redirecționările de host, certificatele, schema canonică, URL-urile interne și resursele încărcate prin HTTP. Conținutul mixt înseamnă că o pagină HTTPS solicită o resursă nesecurizată. De ce contează: solicitările nesecurizate pot fi blocate, expun utilizatorii și creează semnale URL inconsistente. Cum se face: crawl toate variantele HTTP, inspectează acoperirea certificatelor și erorile de securitate ale browserului și caută cereri de resurse randate. Instrument: crawler, panoul de securitate al browserului și configurarea serverului. Finalizat când: fiecare pagină HTTP redirecționează o dată către URL-ul său HTTPS corespunzător, toți canonicii și legăturile interne folosesc HTTPS, certificatele sunt valide pentru fiecare host live și cererile de conținut mixt activ sau pasiv sunt zero.

Instrumente în AmICited

Folosește rapoartele produsului ca dovezi în lista de verificare, nu ca înlocuitor pentru crawl.

• Sitemap-uri și Indexare la https://app.amicited.com/reports/google-search/sitemaps-indexing arată starea sitemap-urilor trimise, avertismentele, erorile și acțiunile de indexare.
• Inspecție URL la https://app.amicited.com/reports/google-search/url-inspection oferă verdictul live Google pentru URL-urile eșantionate și canonicul selectat.
• Crawl Bing la https://app.amicited.com/reports/bing-webmasters/crawl expune activitatea crawler-ului Bing și problemele la nivel de URL.
• Pagini Google Search la https://app.amicited.com/reports/pages ajută la selectarea paginilor de destinație cu valoare ridicată și separă paginile cu vizibilitate de paginile absente din datele de căutare.
• Vizualizare Director la https://app.amicited.com/reports/directory dezvăluie tipare la nivel de secțiune și sprijină investigațiile de adâncime și orfani.
• Sănătate Date la https://app.amicited.com/features/data-health/ înregistrează dacă dovezile conectate sunt suficient de complete pentru a sprijini decizii sigure.

Reguli de decizie

Pragurile creează constatări; ele nu înlocuiesc judecata. Segmentează pe șablon și importanță de afaceri: zece eșecuri la categoria de checkout pot conta mai mult decât o mie de tag-uri de arhivă stricate.

Prioritizează cu impact × efort × încredere. Punctează impactul de la 1–5 pe baza URL-urilor eligibile afectate și a călătoriilor de afaceri. Punctează efortul de la 1–5 ca factor de ușurință, unde 5 înseamnă o schimbare mică, reversibilă și 1 înseamnă un program mare, riscant; înregistrează și estimarea reală în ore sau zile. Punctează încrederea ca 0.5 pentru o ipoteză plauzibilă, 0.75 pentru dovezi repetate sau 1.0 pentru o cauză principală reprodusă. Produsul oferă un ajutor de ordonare, nu o precizie falsă.

Aplică suprascrierea de dependență: o corectare care deblochează alte lucrări depășește un scor mai mare care nu face acest lucru. Eliminarea unui blocaj robots înainte de lansare este mai importantă decât rafinarea tag-urilor de titlu indexate. La același nivel de dependență, abordează cauzele la nivel de șablon înaintea simptomelor.

Livrabil: registrul prioritizat de constatări

Predă un singur registru partajat, nu un export de crawler. Folosește un rând per cauză principală și atașează mostrele URL separat.

Registrul este complet când constatările critice și majore au responsabili și estimări, blocatorii au o secvență, ipotezele sunt etichetate, iar decizia de publicare este explicită.

Ce merge prost

Un raport de 200 de elemente asupra căruia nimeni nu poate acționa

Exporturile crawler-ului confundă observațiile cu deciziile. Grupează URL-urile repetate sub șablonul sau regula care le cauzează, oferă un eșantion reprezentativ și atribuie un singur responsabil. Două sute de URL-uri stricate produse de o singură componentă de navigație reprezintă o constatare cu o singură cauză principală și un domeniu măsurabil, nu două sute de sarcini.

Raportarea simptomelor în loc de cauze

„Pagina neindexată" este un simptom. Cauza poate fi un canonic neintenționat, un șablon orfan, variante subțiri de parametri, o eroare mobilă sau o legătură exclusiv JavaScript. O constatare nu este pregătită pentru prioritizare până când nu identifică cauza controlabilă sau nu etichetează clar următorul test de diagnosticare.

Auditarea accidentală a mediului de staging

Mediul de staging poate avea reguli robots diferite, autentificare, date, șabloane, feature flag-uri și comportament de host. Înregistrează originea de producție și proprietatea Search Console în partea de sus a fiecărui export. Dacă un crawl trebuie să ruleze împotriva staging-ului pentru asigurarea lansării, etichetează-l ca o comparație separată și nu îmbina niciodată metricile sale cu baza de referință de producție.

Evită de asemenea să numeri excluderile deliberate ca pierderi, să tratezi includerea în sitemap ca dovadă de indexare, să testezi doar pagina principală sau să prioritizezi doar după numărul de URL-uri. Definește setul eligibil, segmentează pe șablon și păstrează dovezile de acceptare.

Faza următoare

Următoarea fază, Accesibilitate AI și pregătire pentru agenți , are nevoie de un eșantion stabil din punct de vedere tehnic. Predă inventarul intenționat de URL-uri indexabile, URL-uri reprezentative curate pentru fiecare șablon prioritar, comparații HTML brut și randat, dovezi robots și de răspuns, decizii canonice, excluderi cunoscute și registrul constatărilor deschise.

Nu pretinde că site-ul este „sănătos din punct de vedere tehnic." Precizează care șabloane au trecut porțile de crawl și index, care rămân blocate și dacă publicarea poate continua. Următorul responsabil acceptă atunci când poate testa agenții utilizator specifici AI și extragerea fără a redescoperi defecte de căutare-crawl nerezolvate.

FAQ

Cât de des ar trebui să repetăm un audit tehnic de bază?

Rulează-l înaintea unei migrări, reproiectări, schimbări de domeniu sau a unui program amplu de publicare, apoi repetă verificările afectate după lansare. Monitorizează continuu și repetă o trecere standard când se modifică șabloanele, navigația, randarea sau regulile canonice.

Ce raport de indexare ar trebui să aibă un site sănătos?

Pentru URL-urile deliberate eligibile, 90% sau mai mult este așteptarea de pornire, 80–90% necesită explicații, iar sub 80% este o constatare. Exclude din numitor redirecționările, duplicatele, filtrele și paginile intenționat noindex.

Putem publica conținut în timp ce corectările tehnice sunt în desfășurare?

Doar când noile URL-uri sunt accesibile prin crawl, indexabile, canonicalizate, legate intern și neafectate de defect. Dacă descoperirea sau selecția este blocată, suspendă; noile URL-uri doar extind curățarea.

Avem nevoie de un crawler dacă Search Console este conectat?

Da. Search Console raportează ce a observat Google; un crawler testează site-ul curent și dezvăluie legături, răspunsuri, adâncime, canonic și duplicate. Niciunul nu îl înlocuiește pe celălalt.

Cine deține corectările găsite în audit?

Liderul SEO deține registrul și criteriile de acceptare. Ingineria deține de obicei corectările legate de server, randare, redirecționări, canonic și HTTPS; echipele de conținut pot deține duplicarea și legăturile. Fiecare element are nevoie de o persoană numită.