
Lista de verificare SEO tehnic
Crawling și indexare
Primul lucru la care trebuie să te uiți în timpul auditului tehnic este modul în care site-ul tău este indexat și târât de motoarele de căutare. La urma urmei, dacă paginile de pe site-ul dvs. nu pot fi târâte, ele nu vor fi indexate (cu puține excepții). În consecință, paginile care nu sunt reprezentate în index nu vor participa la clasare.
Parcurgeți raportul de indexare a paginilor în Google Search Console
Cea mai precisă și fiabilă modalitate de a analiza indexarea site-ului dvs. web este să analizați Raportul de indexare a paginilor din Google Search Console. Uitați-vă la raportul privind paginile indexate și verificați ce pagini sunt în index. Vedeți dacă există pagini cu opțiuni de filtrare sau sortare, dacă există pagini de testare sau alte pagini pe care nu doriți să le indexați. De asemenea, uitați-vă la paginile care au fost excluse. Nu toate statusurile din raportul Pagini excluse reprezintă o problemă. Nu trebuie să vă concentrați atenția asupra tuturor paginilor excluse, ci doar asupra celor pentru care comportamentul Google nu corespunde intențiilor dvs. În tabelul de mai jos, puteți vedea statusurile care tind să necesite atenție și o analiză mai aprofundată:
Statut | Ce înseamnă | Ce ar trebui să faceți |
---|---|---|
Eroare de redirecționare | Google nu a reușit să urmărească URL-ul din cauza unor probleme de redirecționare. |
|
Eroare de server | Serverul a returnat o eroare 5xx. |
|
Descoperită – neindexată | Google știe despre pagină, dar nu a explorat-o încă. Indică probleme cu bugetul de crawling. |
|
Căutată – neindexată | Google a vizitat pagina, dar a ales să nu o indexeze. De obicei, indică o calitate scăzută a paginii. |
|
Pagină duplicată fără canonică selectată de utilizator | Google consideră pagina un duplicat, dar nu ați specificat un canonical. |
|
Duplicat, Google a ales un canonic diferit de cel al utilizatorului | Google a ignorat canonic specificat de dvs. |
|
Soft 404 | Pagina pare „goală” sau „nu a fost găsită”, dar returnează un status 200 OK. |
|
Celelalte statusuri probabil că nu semnalează nicio problemă. Cu toate acestea, aceste rapoarte merită, de asemenea, revizuite pentru a vă asigura că paginile nu au fost eliminate, redirecționate, canonicalizate sau blocate din greșeală de la indexare.
Stare | Ce înseamnă | Ce trebuie să știți |
---|---|---|
Pagină alternativă cu eticheta canonică corespunzătoare | Google a recunoscut corect eticheta canonică pe care ați specificat-o. |
|
URL blocat de robots.txt | Google nu poate parcurge pagina. |
|
URL marcat „noindex | Pagina are directiva noindex. |
|
Nu a fost găsită (404) | Pagina nu există. |
|
Blocat din cauza unei cereri neautorizate (401)/ Blocat din cauza accesului interzis (403) | Pagina este blocată de autorizare sau interzisă. |
|
Pagină cu redirecționare | Pagina redirecționează către o alta. |
|
URL blocat din cauza unei alte probleme 4xx | Pagina este inaccesibilă din cauza unei erori 4xx, alta decât 404 (de exemplu, 403, 401, 410 etc.). |
|
În Centrul de ajutor Google, puteți găsi o descriere cuprinzătoare a raportului de pagină, inclusiv exemple de probleme și o explicație detaliată a fiecărui statut. Screaming Frog vă poate ajuta și cu analiza paginilor care sunt indexate sau excluse din index. Pentru a face acest lucru, trebuie să conectați API-ul Google Search Console înainte de a începe urmărirea site-ului. Pentru conectare, accesați Configurare -> Acces API -> Google Search Console. Faceți clic pe Sign in with Google și urmați instrucțiunile.

Source: Screaming Frog
Odată conectat, activați inspecția URL-urilor și, de asemenea, puteți activa opțiunea de a ignora inspecția indexării pentru URL-urile care nu pot fi indexate.

Source: Screaming Frog
Veți putea apoi să vedeți și să comparați starea fiecărei pagini în conformitate cu Search Console (așa cum o vede Google) și starea sa reală, așa cum a fost determinată în timpul procesului de urmărire.

Source: Screaming Frog
Vă rugăm să rețineți că pentru fiecare site sunt disponibile doar 2000 de URL-uri pe zi, astfel încât această metodă este mai potrivită pentru site-urile mici.
Verificați ce se află în sitemap.xml
Sitemap.xml este un fișier XML care furnizează crawlerelor motoarelor de căutare o listă a paginilor unui site, precum și (opțional) informații despre data ultimei lor modificări, frecvența actualizării și prioritatea recomandată de crawl. Acesta este de obicei plasat la rădăcina site-ului, de exemplu: https://example.com/sitemap.xml. Sitemap.xml ajută motoarele de căutare să găsească mai rapid paginile noi sau actualizate. În plus, includerea unei pagini în acest fișier este unul dintre semnalele pentru determinarea versiunii canonice a unei pagini, deși unul slab.

Source: e-commerce sport store
Fișierul sitemap.xml este deosebit de util pentru:
- site-uri noi cu puține legături externe;
- site-urile mari cu multe pagini;
- site-urile cu mult conținut media;
- site-urile de știri care sunt actualizate frecvent.
Sitemap.xml trebuie să conțină toate paginile pe care doriți să le indexați. Puteți utiliza același Screaming Frog sau alte crawlere pentru a analiza paginile incluse în Sitemap.xml. În Screaming Frog, sitemap.xml poate fi scanat separat în Modul listă sau poate fi inclus într-o scanare obișnuită a site-ului. Pentru a face acest lucru, în Configuration -> Spider -> Crawl, activați scanarea XML sitemap și adăugați URL-urile absolute ale sitemap-urilor pe care doriți să le scanați. Nu este recomandat să utilizați diverse servicii online pentru generarea unui sitemap, deoarece acestea pot genera doar un sitemap static care nu va fi actualizat automat. Opțiunea optimă este de a genera sitemap.xml folosind plugin-uri pentru CMS-ul pe care rulează site-ul sau de a scrie un script personalizat care generează sitemap-ul în funcție de condițiile specificate și îl actualizează automat atunci când sunt efectuate modificări pe site. Atunci când generați sitemap.xml, asigurați-vă că fișierul dvs. respectă protocolul sitemap.xml. Pentru aceasta, puteți utiliza diverse validatoare online, cum ar fi https://www.xml-sitemaps.com/validate-xml-sitemap.html. Este necesar să includeți toate etichetele enumerate în protocol? Nu întotdeauna. De exemplu, Google ia în considerare doar etichetele <loc> și <lastmod>. Asigurați-vă că data din eticheta <lastmod> este exactă. Dacă există încercări de manipulare a acesteia, Google poate ignora acest tag.
Asigurați-vă că nu există greșeli în fișierul robots.txt
Fișierul robots.txt este primul loc în care se uită un robot de căutare înainte de a cerceta un site. Acesta determină ce secțiuni ale site-ului pot sau nu pot fi explorate și, ca urmare, ce pagini vor fi indexate de motoarele de căutare. Ar trebui să se afle întotdeauna la adresa https://example.com/robots.txt. Acest fișier este un instrument de gestionare a explorării (nu a indexării!) site-ului. Unele pagini, chiar dacă sunt blocate în robots.txt, pot fi totuși indexate (de obicei dacă există legături interne sau externe către acestea). Astfel de pagini (indexate deși sunt blocate în robots.txt) pot fi văzute în Google Search Console în raportul „Indexate, deși blocate de robots.txt”.

Source: Search Console
Iată ce trebuie să verificați cu privire la fișierul robots.txt ca parte a unui audit tehnic SEO:
- Disponibilitatea fișierului
Fișierul trebuie să fie accesibil la adresa https://example.com/robots.txt și să ofere un status de răspuns 200 OK. Absența sa, erorile de descărcare sau redirecționările (301, 302, 403, 404) pot împiedica motoarele de căutare să înțeleagă corect regulile de crawling ale site-ului.
- Sintaxă și corectitudine
Verificați dacă structura fișierelor respectă standardul. Exemplu de șablon de bază:
- User-agent: *
- Interzis: /admin/
- Permite: /public/
- Hartă site: https://example.com/sitemap.xml

Source: nike.com
- Directivele Disallow și Allow
Verificați dacă paginile importante nu sunt interzise din greșeală, de ex:
- Acasă (/)
- Carduri de produse (/product/)
- Blog sau articole (/blog/, /articles/)
O greșeală frecventă este blocarea imaginilor, stilurilor și scripturilor atunci când se blochează folderele administrative. Într-un astfel de caz, ar trebui specificat că, deși dosarul administrativ este blocat, anumite tipuri de fișiere ar trebui să fie deschise pentru scanare. Acest lucru se întâmplă adesea pe site-urile WordPress atunci când dosarul cu tot conținutul utilizatorului, Disallow: /wp-content este blocat. În acest caz, numai fișierele de un anumit format pot fi deschise pentru scanare:
- Allow: /wp-content/uploads/*.css
- Allow: /wp-content/uploads/*.js
- Permiteți: /wp-content/uploads/*.jpeg
Pentru a vă valida fișierul robots.txt și a testa directivele pe care urmează să le adăugați, puteți utiliza acest instrument.
- Verificați compatibilitatea cu alte directive
Erori apar adesea atunci când robots.txt intră în conflict cu:
- eticheta meta <meta name=”robots” content=”noindex”>
- canonică
De exemplu, dacă o pagină este deschisă în robots.txt, dar blocată prin noindex, aceasta va fi târâtă, dar nu va ajunge în index. Acest lucru este acceptabil, dar este important să fie făcut intenționat. De asemenea, o problemă frecventă este atunci când există alte instrucțiuni pentru roboți în codul sursă și o blocare simultană a paginii în robots.txt. Roboții motoarelor de căutare nu scanează paginile blocate în robots.txt. Ei nu văd etichetele specificate în cod, de exemplu, canonicalizarea. Adică, o astfel de canonicalizare va fi pur și simplu de negăsit.
Verificați legăturile interne
Una dintre sarcinile cheie ale unui audit tehnic este să se asigure că linkingul intern al site-ului funcționează corect. Aceasta înseamnă că toate legăturile interne trebuie să ducă la pagini reale, existente, care sunt deschise pentru indexare, returnează un cod de stare 200 OK, nu conțin redirecționări și, cel mai important, nu trimit la pagini cu erori 4xx/5xx. La prima vedere, acest lucru poate părea un detaliu minor, dar în practică, chiar și legăturile interne incorecte pot afecta negativ:
- Eficiența crawling-ului site-ului de către motoarele de căutare,
- Distribuția ponderii SEO interne (PageRank),
- Experiența utilizatorului.
Primul pas în analiză este verificarea tuturor legăturilor interne pentru erori. Este deosebit de important să se identifice legăturile rupte care conduc la pagini cu o eroare 404, 410 sau alte erori (cum ar fi 403, 500). Mai jos este un tabel cu principalele tipuri de erori care pot apărea în legăturile interne, semnificația lor și acțiunile recomandate pentru a le remedia.
Tip de eroare | Ce înseamnă | Ce trebuie să faceți |
---|---|---|
404 | Pagina nu a fost găsită | Eliminați link-ul sau înlocuiți-l cu unul funcțional |
403 | Acces interzis | Verificați setările de acces |
301/302 | Redirecționați | Actualizați link-ul la URL-ul final |
5xx | Eroare server | Verificați serverul sau CMS-ul |
De asemenea, este important să se analizeze adâncimea ierarhiei paginilor, ceea ce înseamnă să se determine la ce nivel și la câte clicuri distanță de pagina principală se află conținutul cheie. Este de preferat ca paginile importante să nu se afle mai adânc de al treilea nivel – acest lucru crește accesibilitatea lor atât pentru motoarele de căutare, cât și pentru utilizatori. Unul dintre elementele-cheie ale analizei este identificarea paginilor „orfane” – cele care nu au niciun link intern care să indice către ele. Chiar dacă aceste pagini sunt incluse în sitemap, lipsa linkurilor interne le face mai puțin accesibile. În plus, este important să se analizeze textele de ancorare – cuvintele și frazele care conțin linkurile. Acestea ar trebui să fie relevante și semnificative, deoarece textele de ancorare ajută motoarele de căutare să înțeleagă contextul linkului.
Analizați statisticile crawl
Analiza statisticilor de crawl este o modalitate de a înțelege modul în care Googlebot interacționează cu un site: ce pagini sunt crawlate, cât de frecvent și cum afectează acest lucru SEO. Aceste date sunt disponibile în Google Search Console → Settings → Crawl Statistics. În tabelul de mai jos, puteți vedea cele mai frecvente probleme pe care le puteți afla în acest raport:
Problemă | Ce trebuie să căutați în raport | Cauze posibile |
---|---|---|
Scăderea bruscă a crawling-ului | Mai puține explorări pe zi | Probleme de accesibilitate, setări incorecte în robots.txt, blocuri, erori 5xx |
Multe erori 4xx și 5xx | Erori în URL-uri | Pagini șterse, linkuri rupte, probleme ale serverului |
Timpul de răspuns a crescut | >1 secundă – un semn de avertizare | Probleme de găzduire, supraîncărcarea serverului |
Multe redirecționări 3xx | Redirecționări în loc de URL-uri directe | Redirecționări incorecte, lanțuri de redirecționări, un număr mare de linkuri interne cu redirecționări |
CSS/JS nu sunt explorate | Acestea lipsesc din statistici | Blocate de robots.txt |
În plus, jurnalele serverului pot fi analizate. Acestea vă permit să vedeți solicitările reale din partea roboților de căutare (nu numai Googlebot, ci și Bingbot, YandexBot și alții), mai degrabă decât doar datele agregate din Google Search Console. Aceasta este o metodă de diagnosticare avansată, „brută”, care necesită o cantitate semnificativă de timp. Pentru a vizualiza datele, puteți utiliza instrumente open-source precum GoAccess sau Screaming Frog Log File Analyser.
Implementați date structurate
Datele structurate sunt un format special de marcare pe o pagină web care ajută motoarele de căutare să înțeleagă mai precis și mai profund conținutul paginii. Acesta servește ca un „indiciu” pentru Google și alte motoare de căutare cu privire la ce anume se află pe pagină – un articol, un produs, o rețetă, o recenzie, un videoclip etc. Deși nu este un semnal oficial de clasificare, afectează în mod indirect clasificarea prin îmbunătățirea modului în care motoarele de căutare înțeleg pagina. Principalul standard sau protocol utilizat pentru datele structurate pe site-uri web este Schema.org. Există și alte protocoale, cum ar fi OpenGraph, dar acesta este utilizat pentru rețelele sociale. Schema.org este un proiect de colaborare al Google, Microsoft, Yahoo și Yandex, creat pentru a dezvolta și menține un standard unificat pentru datele structurate de pe web. Schema.org include sute de tipuri de entități, cele mai frecvent utilizate fiind enumerate în tabelul de mai jos:
Categorie | Entitate (@type) | Scop |
---|---|---|
Conținut și pagini | Articol | Un articol sau conținut de știri |
BlogPosting | O postare pe blog | |
NewsArticle | Un articol de știri pentru Google News | |
FAQPage | O pagină cu întrebări frecvente (FAQ) | |
HowTo | Un ghid pas cu pas | |
WebPage | Informații generale despre o pagină web | |
Produse și oferte | Produs | Descrierea produsului |
Ofertă | Oferta de preț | |
AgregatOfertă | Gama de prețuri pentru un produs de la diferiți vânzători | |
Recenzii și evaluări | Recenzie | O recenzie a unui produs sau serviciu |
Rating | O evaluare numerică (adesea în cadrul unei recenzii) | |
AggregateRating | Evaluarea medie bazată pe mai multe recenzii | |
Organizații și persoane | Organizație | O descriere a unei companii sau a unui brand |
LocalBusiness | O afacere locală cu informații de contact și program | |
Persoană | O persoană (de exemplu, autor de articole, vorbitor etc.) | |
Eveniment | Eveniment | Un eveniment online sau offline |
Navigare și structură | BreadcrumbList | Navigație Breadcrumbs |
SiteNavigationElement | Elemente de meniu principal | |
Multimedia | VideoObject | Video cu metadate (pentru fragmente video) |
ImageObject | Imagine cu descriere | |
Educație și locuri de muncă | Curs | Un curs online sau un program de formare |
JobPosting | Post vacant (pentru Google for Jobs) |
Se recomandă implementarea datelor structurate în formatul JSON-LD. Acest bloc este plasat în <head> sau <body> al documentului HTML, dar nu este afișat utilizatorului – este citit de roboții de căutare. Toate motoarele de căutare importante, cum ar fi Google, Bing și Yahoo, acceptă acest format. Un exemplu de cod JSON-LD este prezentat mai jos: <script type=”application/ld+json”> {„@context”: „https://schema.org”, „@type”: „Article”, „headline”: „Ce este JSON-LD?”, „author”: {„@type”: „Person”, „name”: „John Smith” }, „datePublished”: „2025-12-01” } </script> Atunci când implementați date structurate, urmați protocolul Schema.org și utilizați validatorul pentru a verifica corectitudinea tipurilor de microdate implementate. unele tipuri de date structurate din protocolul Schema.org pot ajuta, de asemenea, la afișarea snippet-urilor bogate în rezultatele căutării Google. Rețineți că cerințele Google privind datele structurate pentru snippet-urile bogate diferă ușor de standardul Schema.org. Adesea, trebuie specificate mai multe câmpuri decât prevede protocolul Schema.org. Prin urmare, dacă doriți să obțineți o Rich Snippet, urmați instrucțiunile Google pentru datele structurate. Puteți verifica corectitudinea implementării microdatelor utilizând validatorul Rich Snippet. Există, de asemenea, multe generatoare de microdate, dar acestea pot crea doar cod static care nu va fi actualizat odată cu modificările de conținut de pe pagină. Asigurarea că informațiile din microdate corespund cu ceea ce este vizibil pentru utilizatori pe pagină face parte din cerințele Google privind datele structurate. Dacă politica privind datele structurate este încălcată, pagina poate pierde toate snippet-urile bogate și, în unele cazuri, se poate confrunta cu penalizări manuale. Prin urmare, asigurați-vă că microdatele dvs. sunt generate automat și actualizate automat.
Conținutul
Ca parte a unui audit tehnic SEO, este important să evaluați caracteristicile de bază ale conținutului: de la structura titlurilor și a metaetichetelor la prezența atributelor alt pentru imagini și potențiale pagini duplicate. Aceste elemente afectează în mod direct atât indexarea, cât și modul în care motoarele de căutare percep site-ul.
Testați site-ul dvs. pentru duplicate complete
Duplicaturile complete apar atunci când conținutul identic este accesibil prin URL-uri diferite pe site. Duplicaturile pot afecta complet clasamentul site-ului dvs. Cele mai comune tipuri de duplicate complete sunt:
- Accesibilitate atât prin HTTP, cât și prin HTTPS
- Accesibilitate cu și fără WWW
- Accesibilitate cu sau fără o bară oblică terminală
- Accesibilitatea URL-urilor cu majuscule și minuscule
- Accesibilitatea paginii cu extensii de fișier precum .html, .htm, .php, .aspx și fără acestea
- Parametrii care nu modifică conținutul paginii, cum ar fi etichetele UTM
- conținut identic sub adrese URL diferite. De exemplu, un produs este listat în două categorii, accesibile prin două URL-uri diferite. Sau pagina produsului accesibilă cu și fără categorie în URL.
- Versiuni de testare ale site-ului (domeniul DEV utilizat pentru dezvoltare).
Pentru a găsi pagini duplicate legate de variațiile URL, testați manual URL-urile și verificați codul de răspuns al serverului pentru aceste variante de URL. Puteți utiliza orice instrument pentru a verifica codurile de răspuns ale serverului, cum ar fi https://httpstatus.io/. Introduceți variantele URL și verificați accesibilitatea acestora.

Source: httpstatus.io/ website + test of a client’s website
Pentru a rezolva problemele legate de variațiile HTTP/HTTPS, www/fără-www, cu/fără bară oblică, majuscule/minuscule și accesibilitatea paginilor cu extensii precum .html, .htm, .php, .aspx și fără acestea, este necesar să se configureze o redirecționare 301 către versiunea preferată. Atunci când se găsesc duplicate din cauza disponibilității unui conținut identic prin adăugarea sau eliminarea unor părți din URL (de exemplu, un produs este disponibil în două categorii), cel mai bine este să se reconsidere structura URL și structura site-ului. Pentru UTM și alți parametri, canonicalizarea poate fi, de asemenea, o soluție. Cu toate acestea, este important să rețineți că Google tratează eticheta canonică ca pe o recomandare, iar decizia finală cu privire la URL-ul care trebuie ales rămâne la Google. Dacă o versiune de test a site-ului este găsită în indexul Google, aceasta trebuie blocată de la indexare și trebuie trimisă o cerere de eliminare a acesteia prin Google Search Console.
Rezolvarea paginilor duplicate parțial
Dublurile parțiale de pagină apar atunci când două sau mai multe pagini de pe site conțin conținut foarte similar, dar nu complet identic. Cele mai frecvente tipuri de duplicate parțiale sunt:
- Pagini de sortare
- Pagini de filtrare
- Pagini de paginare
- Pagini cu produse similare (de exemplu, produsele diferă doar prin culoare)
- Versiuni multiple ale site-ului în aceeași limbă, dar pentru regiuni diferite (de exemplu, trei site-uri în limba engleză pentru SUA, Regatul Unit și Australia).
Desigur, fiecare site este unic, iar în timpul unui audit tehnic, este posibil să identificați și alte cazuri de conținut duplicat care necesită soluții specifice. Cu toate acestea, exemplele de mai sus sunt cele mai frecvente. Dublurile parțiale sunt, de obicei, găsite în timpul procesului de crawlare a site-ului de către diverse crawlere. Acestea vor avea parametri care se repetă și pot avea același titlu și H1 ca paginile principale ale categoriei. Pentru a elimina duplicatele parțiale, nu puteți configura o redirecționare, deoarece aceste pagini sunt necesare pentru funcționalitatea site-ului. Mai jos, vom discuta metodele de abordare a duplicatelor parțiale.
Sortarea și filtrarea paginilor
Aceste pagini pot fi blocate de la crawlere în fișierul robots.txt, deși acest lucru poate fi ignorat de Google, mai ales dacă link-urile direcționează către aceste pagini. Acest lucru va ajuta la păstrarea bugetului de crawling. De asemenea, le puteți bloca prin directiva <meta name=”robots” content=”noindex, nofollow” />, care va împiedica indexarea acestor pagini, dar nu va spune Google că nu ar trebui să fie crawlate. Cea mai bună abordare în acest caz este să utilizați JavaScript pentru a actualiza conținutul paginii atunci când utilizatorul aplică sortarea sau filtrele, fără a genera URL-uri și linkuri suplimentare către paginile de filtrare sau sortare.
Variante de produse disponibile la URL-uri diferite
În mod ideal, toate variantele de produs ar trebui să fie combinate pe o singură pagină, unde utilizatorul poate selecta culoarea sau dimensiunea dorită fără a modifica URL-ul, utilizând JavaScript. Cu toate acestea, dacă se utilizează o pagină separată pentru fiecare variantă, ar trebui specificată o legătură canonică către pagina principală a produsului. Cu toate acestea, după cum s-a menționat anterior, Google poate ignora legătura canonică setată de utilizator.
Pagini de paginare
Paginile de paginare nu ar trebui să fie blocate de la indexare. Pentru a vă asigura că Google consideră prima pagină a categoriei ca fiind cea principală:
- Includeți numai prima pagină în fișierul sitemap.xml.
- Adăugați un link către pagina principală a categoriei pe toate paginile de paginare.
- Adăugați numere de pagină la titlul și H1 ale paginilor de paginare. De exemplu, „Cămăși albe – pagina 2”.
Pagini disponibile într-o singură limbă, dar pentru regiuni diferite
În acest caz, trebuie utilizate atributele Hreflang. Acestea sunt utilizate pentru a indica motoarelor de căutare limba și versiunea regională a unei pagini web pe care ar trebui să le afișeze utilizatorilor în funcție de preferințele lor lingvistice și de locație. Există mai multe modalități de implementare a atributelor Hreflang:
- În antetele HTTP
- Prin intermediul etichetelor din secțiunea <head>
- Prin intermediul etichetelor din sitemap.xml
Cea mai simplă metodă de implementare este prin intermediul etichetelor din secțiunea <head>. Există reguli pe care atributele hreflang implementate prin intermediul etichetelor din secțiunea <head> trebuie să le îndeplinească:
-
- Atributul trebuie să aibă următorul format: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />
- Codurile de limbă și de țară trebuie să fie valide. Pentru a alege codul valabil pentru fiecare mutație lingvistică, consultați această pagină.
- Fiecare versiune lingvistică trebuie să se listeze pe sine, precum și toate celelalte versiuni lingvistice în atributele sale hreflang. Aceasta înseamnă că fiecare pagină trebuie să aibă același număr de atribute hreflang
- Link-urile din atributele hreflang trebuie să fie absolute și indexabile.
Un exemplu de cod: <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”en-us” /> <link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”en-gb” /> <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”x-default” />
Verificați titlurile, h1, h2s și descrierile pentru duplicate
Deși titlurile, descrierile și antetele H1-H6 sunt legate de SEO on-page, analiza lor în cadrul unui audit tehnic poate fi utilă pentru detectarea dublărilor. Pentru a le aanaliza, puteți utiliza orice crawler care colectează aceste etichete. Atunci când sunt găsite titluri, etichete H1-H6 și descrieri duplicate, analizați datele paginii și identificați cauza dublării. Acest lucru se poate datora disponibilității site-ului atât prin HTTP, cât și prin HTTPS, duplicării etichetelor categoriei principale pe paginile de filtrare sau pur și simplu unei greșeli umane în care aceste etichete au fost completate incorect.
Optimizați atributele alt pentru imagini
Atributele Alt sunt un atribut HTML utilizat în interiorul etichetei <img> astfel: <img src=”image.jpg” alt=” Descrierea imaginii”>. Scopul său principal este de a furniza o descriere text a conținutului imaginii. Acest text este afișat dacă imaginea nu se încarcă și este citit cu voce tare de cititoarele de ecran pentru a ajuta utilizatorii cu deficiențe de vedere. Un text alt adecvat și descriptiv vă poate ajuta imaginile să se claseze în căutarea de imagini și să îmbunătățească relevanța generală a paginii. Dacă aveți un site web cu mult conținut vizual, atunci optimizarea atributelor alt este un pas mai important decât pentru site-urile web clasice care se bazează pe conținut text. Multe crawlere precum Screaming Frog, Ahrefs, SemRush etc. analizează atributele alt și de acolo puteți obține date despre atributele alt lipsă sau goale. Puteți citi mai multe despre crearea de atribute alt descriptive în documentele oficiale Google.
Viteza site-ului web, mobilitatea și ușurința în utilizare
Utilizați protocolul HTTPs
Utilizarea protocolului securizat HTTPS este esențială pentru a asigura securitatea transmiterii datelor între utilizator și server. Acesta nu numai că sporește încrederea utilizatorilor, dar are și un impact pozitiv asupra SEO. Pentru a verifica existența protocolului HTTPS, pur și simplu uitați-vă la bara de adrese a browserului – ar trebui să apară pictograma unui lacăt. Pentru o analiză detaliată, puteți utiliza serviciul SSL Labs, care va furniza un raport complet privind starea certificatului SSL și va identifica eventualele probleme. De asemenea, este important să vă asigurați că nu există conținut mixt – resurse HTTP pe pagini HTTPS. Pentru această analiză, puteți utiliza raportul HTTPS din Google Search Console, care va afișa URL-urile atât cu HTTP, cât și cu HTTPS.

Source: Search Console
Sursă: Search Console a clientului nostru
Îmbunătățiți Core Web Vitals
Core Web Vitals este un set de metrici propuse de Google pentru a evalua calitatea experienței utilizatorului pe un site web. Acești parametri se concentrează pe viteza de încărcare, interactivitate și stabilitatea vizuală a conținutului de pe pagină. Acestea includ trei indicatori cheie:
Metric | Descriere | Valoare optimă |
---|---|---|
Cea mai mare pictură de conținut (LCP) | Măsoară timpul de încărcare al celui mai mare element vizibil de pe pagină (de exemplu, imagine sau text). | Mai puțin de 2,5 secunde |
Întârzierea la prima intrare (FID) | Măsoară timpul necesar paginii pentru a răspunde la prima interacțiune a utilizatorului (de exemplu, clic pe un buton sau un link). | Mai puțin de 100 milisecunde |
Deplasare cumulată a aspectului (CLS) | Evaluează stabilitatea vizuală a paginii, adică cât de mult se mișcă elementele în timpul încărcării paginii. | Mai mică de 0,1 |
Datele care au fost colectate de la utilizatori reali pot fi vizualizate în raportul Search Console „Core web vitals” (date agregate) sau în PageSpeed Insights (pentru teste individuale). În timp ce lucrați la Core Web Vitals, rețineți că trebuie să definiți problemele care au o influență mare asupra parametrilor CWV. De exemplu, în timp ce optimizați LCP, trebuie să definiți care dintre cele 4 aspecte (TTFB, Load Delay, Load Time sau Render delay) contribuie cel mai mult la un scor LCP ridicat. În exemplul de mai jos, este vizibil că nu trebuie să ne concentrăm pe optimizarea TTFB sau Load Time. În schimb, ne putem pune toate energiile în îmbunătățirea întârzierii la încărcare și apoi a întârzierii la redare.

Source: pagespeed.web.dev
Sursă: https://pagespeed.web.dev/ – test al site-ului webnike.com (doar pentru exemplu). Domeniul este încețoșat
Asigurați-vă că site-ul dvs. web este mobil-friendly
Compatibilitatea cu dispozitivele mobile a devenit un factor crucial începând cu 2018, când Google a trecut la o abordare de indexare mobile-first. Acest lucru înseamnă că acum Google utilizează în principal versiunea mobilă a unui site web pentru clasificare și indexare, mai degrabă decât versiunea desktop. În Google Search Console, vă puteți testa paginile făcând clic pe „Test Live URL” în instrumentul de inspecție URL și puteți vedea cum le vede Googlebot-Mobile.
Comprimați imaginile
Optimizarea imaginilor cu scopul de a le comprima fără a pierde din calitate ajută la accelerarea încărcării site-ului, mai ales dacă există mult conținut grafic pe pagini. Instrumente online precum TinyPNG sau Squoosh pot fi utilizate pentru a comprima imaginile. De asemenea, merită să verificați dacă sunt utilizate formate de imagine moderne, cum ar fi WebP, deoarece acestea pot reduce semnificativ dimensiunea fișierelor.
Utilizați CDN pentru site-uri web internaționale
Utilizarea unei CDN are sens dacă site-ul dvs. deservește o gamă largă de regiuni îndepărtate din punct de vedere geografic. O CDN (Content Delivery Network) distribuie conținutul site-ului pe servere situate mai aproape de utilizatori, reducând latența în timpul încărcării. Puteți verifica utilizarea CDN prin examinarea antetelor de solicitare HTTP în instrumentele de dezvoltare ale browserului (fila Rețea), unde pot apărea referințe la furnizorul CDN, cum ar fi Cloudflare sau Akamai. Există, de asemenea, instrumente online pentru testarea CDN. Configurarea CDN se face de obicei prin intermediul panoului de găzduire sau al CMS-ului. Utilizați memoria cache Memoria cache permite browserelor și serverelor proxy să stocheze copii ale resurselor, reducând încărcarea serverului și accelerând încărcarea la vizitele ulterioare. Puteți verifica corectitudinea cachingului în instrumentele de dezvoltare ale browserului – în secțiunea Network, uitați-vă la antetele Cache-Control, Expires și ETag. Google PageSpeed Insights oferă, de asemenea, recomandări pentru caching. Este important ca resursele statice (imagini, scripturi, stiluri) să aibă setări de caching adecvate, iar serverul să aibă configurate regulile corespunzătoare (de exemplu, în .htaccess sau în configurația nginx). Pentru a verifica cachingul, puteți utiliza servicii online precum GiftOfSpeed.
Concluzie
Auditul tehnic al unui site web nu este o procedură unică, ci un proces continuu care necesită acordarea unei atenții regulate factorilor tehnici care pot afecta performanța și vizibilitatea acestuia. Deoarece fiecare site web este unic, accentul specific și frecvența verificărilor vor varia. Această listă de verificare pentru un audit tehnic SEO vă va ajuta să vă asigurați că nu ați uitat nimic important.