Ghid Sanramses Marketing
Cum faci un audit tehnic SEO reproductibil
Proces practic pentru verificarea crawlingului, indexabilității, statusurilor HTTP, canonicalelor, sitemapului, renderingului și datelor structurate.
Un audit tehnic SEO este reproductibil când aceeași verificare, executată în aceleași condiții, produce dovezi comparabile înainte și după remediere. Fiecare constatare trebuie să păstreze testul, rezultatul brut, interpretarea, acțiunea și retestarea. O etichetă precum „problemă de indexare” fără aceste elemente nu este suficientă.
Definește mediul și protocolul înainte de crawl
Notează domeniul, protocolul, hostname-ul preferat, data, instrumentul și versiunea, user-agentul, punctul de pornire și sursele de URL-uri. Un crawl pornit doar din homepage nu demonstrează că ai găsit URL-urile orfane; combină sitemapul, baza CMS, linkurile interne și, dacă există acces, datele Search Console ori logurile.
- Care este mediul: producție, staging sau copie locală?
- Ce variante de host și protocol sunt incluse?
- Ce limită și ce reguli de crawl folosește instrumentul?
- Ce autentificare ori cookie influențează răspunsul?
- Ce fișiere brute și ce hashes vor permite comparația?
Google descrie separat etapele de crawling, indexare și servire în documentația despre funcționarea Search. O problemă observată într-o etapă nu trebuie atribuită automat alteia.
1. Răspuns HTTP, variante și redirecturi
Pentru fiecare URL important păstrează statusul inițial, locațiile intermediare și destinația finală. Verifică separat HTTP/HTTPS, www/non-www, slash și variantele cunoscute. Un browser care ajunge la pagina finală poate ascunde un lanț inutil sau o buclă pe care auditul trebuie să o arate.
| TEST | RAW_RESULT | INTERPRETATION | ACTION | RETEST |
|---|---|---|---|---|
| HEAD/GET pentru URL | Status, Location și antete, datate | Răspuns direct, redirect intenționat sau eroare | Numai după confirmarea URL-ului preferat | Aceeași cerere, același user-agent |
| Variantă HTTP | Lanț complet | Consolidare sau buclă | Un singur salt când arhitectura o permite | Verificare variantă și destinație |
| URL inexistent | Status și corp | 404 real ori posibil soft 404 | Corectarea linkului sau răspunsului justificat | Link și status final |
2. Robots.txt, meta robots și X-Robots-Tag au roluri diferite
Verifică robots.txt ca fișier separat: status, sintaxă, reguli pentru user-agent și declarația sitemapului. Apoi inspectează HTML-ul și antetele fiecărei pagini. Nu deduce directiva unei pagini din setarea generală a CMS-ului; citește răspunsul efectiv.
- robots.txt: poate permite sau bloca solicitarea unei căi.
- meta robots: indică modul de indexare pentru documentul HTML accesat.
- X-Robots-Tag: poate transmite directive prin antet, inclusiv pentru fișiere non-HTML.
- autentificare: protejează conținutul privat; noindex nu este control de securitate.
Google explică aceste controale în secțiunea oficială despre crawling și indexare.
3. Canonicalul și sitemapul sunt semnale, nu comenzi absolute
Colectează canonicalul declarat, URL-ul final, includerea în sitemap și legăturile interne. Semnalele trebuie să fie coerente. Nu lista în sitemap o variantă și nu indica alta prin canonical fără motiv documentat.
Documentația Google despre canonicalizare descrie redirecturile și rel=canonical ca semnale puternice, iar sitemapul ca semnal mai slab. Google poate alege totuși alt canonical. Auditul trebuie să spună „canonical declarat” și, când datele sunt disponibile, „canonical selectat de Google”, nu să le confunde.
Checklist canonical
- Este URL absolut, valid și accesibil?
- Pagina canonicală este indexabilă?
- Canonicalul contrazice redirectul sau sitemapul?
- Variantele aproape identice indică aceeași destinație justificată?
- Legăturile interne folosesc în principal URL-ul preferat?
Sitemapul trebuie să conțină URL-urile canonice pe care proprietarul dorește să le vadă în rezultate. Trimiterea sitemapului nu garantează crawlingul sau indexarea, conform ghidului Google pentru sitemapuri.
4. Indexabil tehnic nu înseamnă indexat
O pagină poate răspunde 200, poate permite crawlingul, poate avea canonical self și poate apărea în sitemap, dar să nu fie selectată pentru index. Auditul tehnic poate confirma eligibilitatea observabilă; indexarea efectivă necesită date precum inspecția URL ori rapoartele Search Console, dacă sunt disponibile.
| Afirmație | Dovadă necesară | Formulare corectă |
|---|---|---|
| Pagina este indexabilă tehnic | 200, acces, directive, canonical și conținut | Nu am identificat un blocaj tehnic în testul efectuat. |
| Pagina este indexată | Date de inspecție/indexare disponibile | Sursa și data confirmării sunt menționate. |
| Pagina va fi indexată | Nu poate fi garantat | Pagina este pregătită tehnic pentru evaluare. |
5. Rendering, conținut principal și resurse
Compară HTML-ul primit cu DOM-ul randat atunci când JavaScript construiește sau modifică informația importantă. Verifică dacă titlul, H1, conținutul principal, linkurile și datele structurate există în forma pe care motorul o poate procesa. Examinează resursele blocate, erorile JavaScript și conținutul care apare numai după interacțiuni.
- HTML brut conține informația principală sau doar un container gol?
- Linkurile sunt elemente accesibile cu destinații crawlable?
- Conținutul se schimbă între mobil și desktop?
- Resursele importante răspund și nu sunt blocate?
- Un fallback rămâne disponibil când un script eșuează?
Nu orice diferență dintre HTML și DOM este o eroare. Problema apare când diferența împiedică accesul, interpretarea ori acțiunea.
6. Verifică semnalele paginii împreună
Title-ul, meta descrierea, H1, introducerea, canonicalul, schema și legăturile interne trebuie să descrie aceeași intenție. Auditul nu marchează automat drept eroare orice title lung ori orice pagină scurtă; verifică rolul, unicitatea și potrivirea.
Semnale de interpretare
- Title și H1 unice și descriptive.
- Un singur proprietar principal al intenției.
- Introducere care răspunde rapid problemei.
- Linkuri interne cu ancore naturale.
Semnale de risc
- Mai multe URL-uri aproape identice.
- Canonical către o pagină cu altă intenție.
- Conținut principal ascuns după interacțiune.
- Pagini orfane sau fără traseu comercial.
7. Structured data: validitatea nu garantează afișarea
Extrage toate blocurile JSON-LD, verifică sintaxa, tipurile, URL-urile și relațiile. Confirmă că informația este vizibilă și adevărată. Nu adăuga recenzii, ratinguri, persoane sau servicii pe care pagina nu le susține.
Păstrează rezultatul brut al validatorului, data și fragmentul testat. Dacă schema este generată dinamic, retestează după schimbări de temă, plugin sau șablon.
8. Core Web Vitals: context de experiență, nu diagnostic complet
LCP, INP și CLS descriu încărcarea principală, răspunsul la interacțiune și stabilitatea vizuală. Datele de teren și testele de laborator au roluri diferite. INP, de exemplu, depinde de interacțiuni reale, iar un test de laborator folosește indicatori de diagnostic, nu reproduce toate sesiunile.
Ghidul web.dev despre măsurarea Web Vitals explică diferențele dintre instrumente și limitele măsurării de laborator. Auditul trebuie să noteze dacă rezultatul provine din field data sau lab data, dispozitivul, rețeaua și pagina testată.
Technical Audit Evidence Ledger
| URL/ASSET | TEST | RAW_RESULT | INTERPRETATION | ACTION | RISK | RETEST |
|---|---|---|---|---|---|---|
| Destinația exactă | Comandă, instrument, versiune și condiții | Export, status, antet ori captură | Concluzie limitată la dovadă | Schimbare delimitată | Impact și rollback | Același test după schimbare |
Regula de închidere
O constatare este închisă numai când acțiunea este aplicată, retestarea a trecut, nu a apărut o regresie și dovada a fost atașată. Dacă schimbarea implică redirect, canonical, noindex sau ștergere, păstrează aprobarea și rollback-ul.
Pentru relația dintre implementarea tehnică, structura comercială și conținut, vezi serviciul Sanramses de website și SEO local. Pentru designul proprietarilor editoriali, continuă cu ghidul despre harta topică.
Arhitectură și linkuri interne
Construiește graful linkurilor și distanța față de homepage sau hub. Separă navigarea, footerul, breadcrumb-ul și contextul editorial. O pagină importantă poate fi descoperită prin sitemap, dar legăturile interne slabe nu comunică bine rolul ei.
- Orfane: URL-uri fără link intern crawlable.
- Near-orphans: primesc doar o legătură tehnică.
- Money pages fără suport contextual.
- Huburi transformate în liste fără ierarhie.
- Ancore exacte repetate mecanic.
Nu forța profunzimea prin legături fără motiv semantic. Pentru fiecare candidat notează sursa, ținta, ancora, motivul și riscul.
Parametri, paginare și arhive
Inventariază variantele generate de parametri, slash, căutare, arhive și paginare. Compară title, H1, canonical și conținut. O paginare legitimă poate lista elemente unice, iar o rută accidentală poate reproduce homepage-ul; nu aplica aceeași soluție ambelor cazuri.
Prioritizează fără scor arbitrar
P0 include 5xx, blocare globală, noindex accidental și canonical sistemic greșit. P1 acoperă pagini comerciale inaccesibile sau conținut principal nerandabil. P2 privește structura și legăturile; P3 optimizările incrementale. Înainte de schimbări cu impact larg, verifică backup-ul și rollback-ul.
Ai nevoie de un diagnostic care poate fi retestat?
Evaluarea tehnică Sanramses păstrează testele, dovezile și limitele fiecărei concluzii înainte de recomandarea unei schimbări.