19 probleme tehnice comune SEO (cu soluții recomandate)

La Semetrical, specialiștii noștri SEO au efectuat nenumărate audituri tehnice SEO de-a lungul anilor și au întâlnit probleme tehnice comune pe care site-urile web le suferă în mai multe industrii. Ghidul nostru prezintă cele mai comune probleme tehnice SEO cu soluții recomandate.

Mai jos sunt enumerate cele mai frecvente probleme tehnice SEO:

1. Reguli care nu țin cont de majuscule și minuscule în roboți,txt
2. Dublare URL cu majuscule și minuscule
3. Redirecționare HTTP 302 către HTTPS
4. URL-uri canonice care afectează legătura internă
5. URL-uri canonice care se leagă la 404 URL-uri
6. Etichete canonice multiple
7. Dublarea paginii de pornire
8. Versiunea pentru mobil și desktop a site-urilor diferă
9. Detectare IP internațională
10. Dublarea site-ului internațional
11. Harta site-ului XML, inclusiv URL-uri istorice și URL-uri intermediare
12. Site-ul web este indexat, provocând dublarea
13. Căutarea internă este indexată
14. Parametrii care cauzează dublarea
15. Dublare URL a produsului
16. Adâncimea unui site web
17. JavaScript
18. Utilizarea incorectă a Meta Robots NOINDEX
19. Soft 404 pagini

1. Reguli care nu țin cont de majuscule și minuscule în Robots,txt

Problema:

Atunci când efectuăm audituri tehnice SEO, constatăm adesea că regulile de interzicere din robots.txt nu se potrivesc atât cu majuscule, cât și cu litere mici.

De exemplu, pe site-urile de comerț electronic, căile coșului rulează adesea atât pe /basket/, cât și pe /Basket/, dar numai calea cu litere mici este inclusă ca regulă în robots.txt. Aceasta înseamnă că adresele URL cu /Coș/ ar fi în continuare indexabile și asta ar provoca duplicarea conținutului, pe care trebuie să o evitați pentru o indexare îmbunătățită a site-ului dvs. pe motoarele de căutare.

Reguli Robots.txt:

Nu permiteți: /coș/

Nu permiteți: /basket/*

Soluţie:

Auditează-ți site-ul web și verifică dacă există atât versiuni majuscule, cât și litere mici ale unei căi care trebuie blocată. Puteți face acest lucru folosind un crawler web, cum ar fi prietenii noștri de la DeepCrawl. Dacă există ambele versiuni active pe site, adăugați o a doua regulă în robots.txt pentru a asigura blocarea căii cu majuscule. De exemplu, Disallow: /Basket/*

Dacă nu aveți acces la un crawler web, atunci o căutare a protocolului de site poate fi foarte utilă pentru a vedea dacă sunt indexate atât versiunile majuscule, cât și cele mici.

2. Dublare URL cu majuscule și minuscule

Problema:

O problemă obișnuită pe care o găsim este duplicarea adreselor URL care nu țin seama de majuscule și minuscule la care se leagă pe un site web, iar Google vede că acestea sunt două adrese URL diferite. De exemplu:

Acest lucru se poate întâmpla din cauza editorilor de pe o postare de blog care adaugă un link direct către pagina unui produs, dar au introdus o literă mare în loc de literă mică.

Am văzut că acest lucru se întâmplă și din cauza modulelor de conectare interne care au o eroare la care linkurile de produse populare sunt legate prin litere mari.

Soluţie:

Vă recomandăm să configurați o regulă la nivel de server în care toate adresele URL cu majuscule redirecționează la litere mici printr-o redirecționare 301. Acest lucru va proteja site-ul web de orice duplicare viitoare la care sunt legate atât o adresă URL cu majuscule, cât și litere mici.

Adăugarea unei reguli de redirecționare 301 va consolida, de asemenea, orice echitate a link-urilor în cazul în care un site extern poate trimite la site-ul dvs. din greșeală printr-o literă mare.

Dacă o redirecționare 301 nu este posibilă, vă recomandăm să adăugați o etichetă canonică în codul sursă al adreselor URL cu majuscule pentru a face referire la versiunea URL cu litere mici.

3. HTTP 302 redirecționare către HTTPS

Problema:

Companiile își migrează adesea site-ul web pentru a securiza adrese URL HTTPS, dar nu implementează întotdeauna o regulă de redirecționare 301 și, în schimb, implementează o redirecționare 302, astfel încât, în teorie, aceasta le spune motoarelor de căutare că versiunea HTTP a unei adrese URL s-a mutat doar temporar și nu permanent. Acest lucru poate reduce echitatea link-urilor și autoritatea generală a site-ului dvs., deoarece adresele URL HTTP care au dobândit backlink-uri de-a lungul timpului nu vor trece complet peste echitatea link-ului către versiunea HTTPS, decât dacă există o redirecționare 301.

Soluţie:

Vă recomandăm să configurați o regulă la nivel de server în care toate adresele URL HTTP 301 redirecționează către versiunea HTTPS.

4. URL-uri canonice care afectează legătura internă

Problema:

Pe o serie de site-uri de comerț electronic, am văzut produse care au mai multe variații ale adresei URL ale produsului, dar fiecare variantă trimite la o adresă URL canonică a produsului pentru a preveni duplicarea. Cu toate acestea, pagina de produs canonică poate fi găsită numai prin etichete canonice și fără alte link-uri interne.

În plus, pagina de produs canonică nu include niciun fel de pesmet care să afecteze legătura internă pe site.

Această configurație canonică de legături interne a împiedicat uneori motoarele de căutare să preia versiunea URL canonică din cauza ignorării instrucțiunilor, deoarece legăturile interne de pe întregul site trimit semnale mixte. Acest lucru poate duce la indexarea versiunilor non-canonice ale produselor, ceea ce provoacă canibalizarea URL-ului – în cele din urmă, impactând negativ performanța SEO.

Soluţie:

Pentru a ajuta adresele URL canonice să fie indexate, site-urile web ar trebui:

Adăugați adresele URL canonice la harta site-ului XML și nu celelalte variante de adrese URL

Link intern către versiunile URL canonice în modulele de linkuri interne la nivelul întregului site, cum ar fi „produse populare”

Adăugați o structură principală de tip breadcrumb la pagina URL canonică.

5. URL-uri canonice care leagă la 404 URL-uri

Problema:

Adresele URL canonice fac referire ocazional la 404 URL-uri, dar aceasta trimite semnale mixte la căutare

motoare. Adresa URL canonică indică unui crawler adresa URL preferată să indexeze, dar URL-ul preferat nu mai există în prezent.

Soluţie:

În primul rând, ar trebui să stabiliți dacă URL-ul canonic ar trebui să fie un 404 sau dacă ar trebui restabilit. Dacă este reinstalat, problema este rezolvată, totuși, dacă URL-ul canonic ar trebui să fie un 404, atunci ar trebui să alegeți o nouă adresă URL canonică sau să actualizați cea canonică pentru a fi auto-referință.

6. Etichete canonice multiple

Problema:

În codul HTML al unei pagini web, uneori pot fi găsite două etichete canonice. Acest lucru poate trimite mesaje conflictuale către un motor de căutare și doar primul canonic va fi numărat și utilizat.

Soluţie:

Unii crawler-uri de site-uri web pot semnala mai multe etichete canonice, totuși, dacă nu este cazul, atunci ar trebui să configurați o extracție personalizată atunci când accesați cu crawlere site-ul pentru a căuta mai multe etichete canonice.

Paginile web cu mai multe etichete canonice în codul HTML trebuie actualizate acolo unde una este eliminată și rămâne doar eticheta canonică corectă.

7. Dublarea paginii de pornire

Problema:

Site-urile web au ocazional mai multe adrese URL de pagină de pornire, ceea ce provoacă dublarea și poate cauza o împărțire a echității link-urilor. Adresele URL comune de duplicare a paginii de pornire includ:

www.example.com

www.example.com/home

www.example.com/index.html

www.example.com/home.html

Soluţie:

Dacă site-ul dvs. are mai multe adrese URL de pagină de pornire, vă recomandăm să configurați o redirecționare 301 în care toate versiunile de duplicare să redirecționeze către versiunea principală a paginii de pornire.

8. Versiunea pentru mobil și desktop a site-urilor diferă

Problema:

Site-urile mobile ar trebui să conțină același conținut ca și versiunea desktop a unui site web. Când efectuăm audituri ale site-urilor web și comparăm accesările cu crawlere pe desktop cu cele mobile, am întâlnit diferențe de conținut în care versiunea mobilă conține mai puțin conținut decât versiunea desktop pe anumite pagini.

Acest lucru poate cauza probleme deoarece aproape toată indexarea unui site web provine din versiunea mobilă și, dacă lipsește conținut prioritar, clasamentele pot începe să scadă.

Soluţie:

Versiunea mobilă a unui site trebuie să conțină același conținut ca și versiunea desktop, iar conținutul lipsă trebuie adăugat pe site-ul mobil.

9. Detecția IP internațională

Problema:

Pentru site-urile web care au implementat redirecționări geografice IP, cea mai comună problemă este aceea că implementarea redirecționează pentru toți utilizatorii, inclusiv roboții.

De obicei, Googlebot va accesa cu crawlere de pe o IP din SUA și, dacă boții sunt redirecționați în funcție de locația geografică, Googlebot va accesa cu crawlere și va indexa doar versiunea din SUA a unui site web. Acest lucru va împiedica accesarea cu crawlere și indexarea altor versiuni geografice ale site-ului.

În plus, acest lucru poate cauza probleme pentru prețurile produselor. Schema de markup pe site-urile de comerț electronic unde prețurile sunt actualizate în funcție de locația geografică, deoarece numai prețul din SUA va apărea pe toate piețele. De exemplu, fragmentul de mai jos arată prețurile din SUA care apar pe versiunea din Regatul Unit a unui site web din Regatul Unit.

Soluţie:

Dacă trebuie să implementați redirecționări IP geografice, vă recomandăm să excludeți toți roboții din regulile de redirecționare, deoarece acest lucru va permite roboților precum Googlebot să acceseze cu crawlere și să indexeze toate versiunile internaționale.

Dacă nu implementați redirecționări IP geografice, vă recomandăm să vă păstrați site-urile web deschise pentru toți utilizatorii din orice locație geografică și să afișați un banner JavaScript ușor de utilizat, care permite utilizatorilor să își aleagă propria limbă/locație.

Aceasta este o caracteristică UX utilă dacă un utilizator a ajuns pe versiunea incorectă a site-ului internațional. Fereastra pop-up va apărea pe baza detectării IP, de exemplu, dacă un utilizator ajunge pe site-ul web din SUA de la o IP din Regatul Unit, va apărea banner-ul care îi spune utilizatorului că site-ul din Regatul Unit poate fi mai potrivit.

10. Dublarea site-ului internațional

Problema:

Este obișnuit să vedeți mai multe versiuni ale unui site web atunci când companiile operează în diferite țări din întreaga lume. Aceasta este o practică obișnuită, deoarece în mod ideal doriți să oferiți cea mai bună experiență de utilizare și, pentru a face acest lucru, site-urile web specifice țării permit companiilor să adapteze călătoria utilizatorului în funcție de locul în care se află utilizatorul în lume.

Cu toate acestea, companiile pot face greșeala de a crea mai multe versiuni ale site-ului lor web, dar nu trimit niciun semnal către motoarele de căutare pentru a indica ce site ar trebui să vizeze o anumită țară sau regiune.

Atunci când proprietarii de site-uri web creează mai multe versiuni de site fără instrucțiuni pentru motoarele de căutare, acest lucru poate provoca haos, cum ar fi duplicarea site-ului web și canibalizarea pe mai multe domenii.

Soluţie:

Atunci când creați versiuni internaționale ale site-ului dvs. web, etichetele Hreflang ar trebui să fie utilizate pentru a semnala motoarelor de căutare, cum ar fi Google, pagina web corectă pe care să o difuzeze utilizatorului, în funcție de locația și limba lor.

Etichetele Hreflang împiedică, de asemenea, ca versiunile internaționale ale unui site web să fie văzute ca duplicate pentru motoarele de căutare, deoarece eticheta Hreflang indică în esență că este necesară o anumită pagină pentru a servi un utilizator în locația X cu setare de limbă X.

Configurarea și maparea etichetelor Hreflang poate deveni confuză și este o sarcină mare, în funcție de dimensiunea site-ului dvs. Dacă este configurat incorect, poate fi dăunător pentru traficul site-ului dvs.

Vă rugăm să vizitați pagina noastră internațională de servicii SEO dacă sunteți în proces de planificare a unei extinderi internaționale a site-ului web sau dacă aveți probleme cu site-urile dvs. internaționale.

11. Harta site-ului XML, inclusiv URL-uri istorice și URL-uri intermediare

Problema:

O problemă interesantă pe care o întâlnim mai des decât ați crede este că site-urile web care au adrese URL vechi în hărțile lor de site XML sau adrese URL de punere în scenă se strâng cumva într-o hartă de site XML.

Acest lucru poate cauza probleme, deoarece adresele URL de pregătire apar în hărțile dvs. de site și site-ul dvs. de pregătire ar putea să nu fie blocat de motoarele de căutare, aceste adrese URL ar putea începe să fie indexate și, la rândul lor, ar putea provoca dublari inutile.

Adresele URL istorice din harta site-ului dvs. care oferă acum un cod de stare 4xx sau 3xx pot trimite semnale confuze către motoarele de căutare pe care pagini doriți să fie accesate cu crawlere sau indexate.

Soluţie:

Asigurați-vă că auditați harta site-ului XML în mod regulat, urmărind Search Console și monitorizând erorile care apar sau configurați o accesare cu crawlere obișnuită într-un instrument precum Deepcrawl.

Configurarea unei accesări obișnuite a sitemap-urilor XML în Deepcrawl este foarte utilă, deoarece aceasta poate semnala rapid orice URL care nu ar trebui să apară în harta dvs. de site și vă permite să fiți la curent cu această problemă potențială.

12. Staging site-ul web fiind indexat provocând duplicarea

Problema:

În mod surprinzător, un număr de companii au site-urile lor web indexabile la motoarele de căutare precum Google, nu intenționat, ci din greșeală. Acest lucru poate provoca o dublare semnificativă, deoarece site-ul web de punere în scenă va fi de obicei o replică a mediului dvs. live. De la o simplă căutare a unui protocol URL pe Google, există milioane de pagini web de punere în scenă live și indexabile.

Soluţie:

La Semetrical, vă recomandăm să adăugați un strat de autentificare în care trebuie să introduceți un nume de utilizator și o parolă pentru a accesa site-ul web de organizare. Adăugarea unei reguli de interzicere este, de asemenea, o opțiune pentru a preveni indexarea mediilor de staging, totuși este mai bine să implementați aceasta dacă site-ul de staging nu a fost deja indexat. De exemplu:

Agent utilizator: *

Nu permite: /

Cele mai multe instrumente de crawler pentru site-uri web au o funcționalitate de suprascrie robots.txt, astfel încât să puteți anula cu ușurință regula de interzicere atunci când efectuați teste în mediul dvs. de pregătire.

13. Căutarea internă în curs de indexare

Problema:

Adresele URL interne de căutare de pe site-uri web pot fi grozave pentru SEO, unde le permite site-urilor web să se clasifice pentru interogări de căutare cu coadă super lungă sau să se clasifice pentru cuvintele cheie în care nu au o adresă URL principală pentru clasare.

Cu toate acestea, în multe cazuri, paginile de căutare interne pot provoca o mulțime de dublari pe site-uri web și pot provoca, de asemenea, probleme de buget de accesare cu crawlere pe site-uri web la scară largă. Pentru acest ghid ne vom concentra pe partea negativă a căutării interne.

Paginile de căutare interne sunt de obicei de foarte slabă calitate, deoarece nu vor fi optimizate și de multe ori vor fi clasificate drept conținut subțire deoarece vor găzdui un număr redus de rezultate, cum ar fi produse.

Soluţie:

Înainte de a decide să blocați paginile de căutare interne, este recomandat să verificați dacă aceste pagini nu se clasifică în prezent pentru niciun cuvânt cheie și nu aduc trafic regulat.

În plus, verificați dacă aceste adrese URL nu au creat backlink-uri de-a lungul anilor. Dacă paginile dvs. interne de căutare nu au backlink-uri autorizate și nu generează trafic organic, atunci la Semetrical vă recomandăm doi pași:

Pasul unu: Adăugați etichete NOINDEX, FOLLOW în toate paginile de căutare pentru a permite motoarele de căutare să deindexeze aceste pagini. Odată ce aceste pagini au fost de-indexate timp de câteva luni, vom implementa pasul doi.

Pasul doi: adăugați directorul intern de căutare în fișierul robots.txt, cum ar fi Disallow: */search*

14. Parametrii care cauzează dublarea

Problema:

Dublarea parametrilor de sortare și filtrare poate fi o problemă comună la auditarea site-urilor web. Multe site-uri web vor folosi filtre, deoarece pot îmbunătăți experiența utilizatorului și le pot permite utilizatorilor să filtreze rezultatele căutării. Cu toate acestea, principala problemă este când site-urile web păstrează filtrele indexabile, deoarece acest lucru generează o cantitate semnificativă de duplicare pe site. De exemplu:

Ocazional, vom întâlni site-uri web care adaugă parametri de urmărire la sfârșitul adreselor URL de pe link-urile interne pentru a indica unde din site s-a făcut clic pe acel link. Nu am recomanda această configurare în primul rând, totuși, atunci când site-urile au deja acest lucru, poate provoca o mulțime de dublari pe un site web, deoarece poate crea mai multe versiuni ale aceleiași pagini. De exemplu:

Alți parametri de urmărire obișnuiți care pot cauza duplicarea sunt parametrii de urmărire UTM, în care linkurile sunt utilizate pentru anumite campanii pentru a urmări performanța campaniei. De exemplu:

Soluţie:

Există o serie de moduri de a preveni indexarea parametrilor și cauzarea dublării, acestea includ:

Canonizarea URL-ului parametrului la versiunea URL curată

Adăugarea unei reguli în fișierul robots.txt pentru a interzice anumite parametri

Adăugarea de parametri la instrumentul de parametri URL din Search Console, ceea ce semnalează Google că anumiți parametri nu trebuie accesați cu crawlere.

15. Dublare URL a produsului

Problema:

Pe site-urile de comerț electronic, duplicarea adreselor URL ale produselor poate fi o problemă mare, precum și pe site-urile editorilor. Motivul principal pentru duplicarea adresei URL a produsului este că produsele pot moșteni categoria/subcategoria din structura sa URL și, dacă produsul se află în mai multe categorii/subcategorii, atunci sunt create mai multe adrese URL.

Pe site-urile web ale editorilor, documentele se pot afla, de asemenea, în mai multe zone și, dacă URL-ul documentului moștenește locația documentului, sunt create mai multe versiuni. De exemplu:

Soluţie:

Când întâlnim o duplicare ca aceasta, există diferite moduri de a o curăța, astfel încât să ne asigurăm că versiunea URL corectă este accesată cu crawlere și indexată.

Pentru a remedia duplicarea adresei URL, vă recomandăm să canonizați toate variantele de adrese URL ale produsului către versiunea părinte sau către o versiune generică. De exemplu:

Exemplu canonic părinte

femeie-colecții-rochii-rochii-de-zi

/71hdo/bella-lula-mini-rochie-florală

s-ar canoniza la:

femeie-colecții-rochii

/71hdo/bella-lula-mini-rochie-florală

Exemplu canonic generic:

femeie-colecții-rochii-rochii-de-zi

/71hdo/bella-lula-mini-rochie-florală

femeie-colecții-rochii

/71hdo/bella-lula-mini-rochie-florală

S-ar canoniza la

Alternative:

Dacă aveți acces la dezvoltatori, atunci o soluție alternativă ar fi să faceți linkuri interne la articolele canonice ale produsului pe tot site-ul web și să redirecționați 301 toate adresele URL ale produselor care rulează din categorii/subcategorii către adresa URL generică a produsului canonic.

Acest lucru ar opri duplicarea produselor și vă va permite să vă conectați la produse prin mai multe rute

16. Profunzimea unui site web

Problema:

Adâncimea paginii este numărul de clicuri pe care o anumită pagină are de pe pagina de pornire a unui site web. Când efectuăm audituri ale site-urilor web, întâlnim site-uri web care au o adâncime mai mare de 10. Aceasta înseamnă că aceste pagini sunt la 10 clicuri distanță de pagina de pornire!

Cu cât sunt necesare mai multe clicuri pentru a găsi o pagină web, cu atât este mai greu pentru un motor de căutare să găsească acea adresă URL și este mai probabil ca adresa URL să nu fie revizuită la fel de des ca paginile mai sus pe site.

În plus, cu cât o pagină este mai înaltă în arhitectura site-ului dvs., cu atât este mai mare șansa ca aceasta să fie văzută ca o pagină prioritară de către motoarele de căutare. Dacă paginile prioritare sunt mai jos în arhitectură, există riscul ca acestea să nu fie la fel de bine clasate.

Soluţie:

Principalele modalități de îmbunătățire a profunzimii site-ului web și de a vă asigura că paginile prioritare sunt sus în arhitectura site-ului includ:

Legături interne pe site, cum ar fi produse recomandate, produse conexe și pagini prezentate

Utilizarea breadcrumb-urilor pe site

Configurarea paginii unde include prima, ultima și cele două pagini de rezultate de fiecare parte a paginii pe care vă aflați

Efectuarea cercetării cuvintelor cheie pentru a descoperi pagini de categorie superioară care ar trebui să fie conectate în navigarea principală a unui site web și adăugarea de link-uri către paginile prioritare

17. Probleme tehnice seo JavaScript

Problema

O mulțime de site-uri web de astăzi vor folosi JavaScript, totuși, la dezactivarea JavaScript, unele site-uri web nu sunt complet funcționale și link-urile pot dispărea și nu vor fi descoperite de motoarele de căutare. Aceasta este o problemă tehnică comună SEO.

Adesea vedem că modulele „s-ar putea să vă placă” de pe paginile produselor de comerț electronic nu pot fi văzute de crawlerele motoarelor de căutare, ceea ce face ca modulul de conectare intern să fie redundant.

În plus, modulele de revizuire care includ UGC bogat în cuvinte cheie se află în modulele JavaScript care, de asemenea, nu pot fi descoperite de crawlere.

O problemă interesantă pe care o au diverse site-uri web de comerț electronic este că atunci când se dezactivează JavaScript pe paginile de rezultate, linkurile de produse pot fi încă găsite, dar toate imaginile dispar, deoarece nu există o opțiune de rezervă pentru ca imaginile să fie descoperite.

Soluţie:

Colaborați cu echipa de dezvoltare pentru a încerca să creați o rezervă JavaScript în care imaginile sunt încă prezente în codul sursă, iar modulele JavaScript pot fi accesate cu crawlere prin HTML.

O modalitate excelentă de a testa modul în care este indexat conținutul JavaScript este să accesați versiunea stocată în cache a paginii dvs. web și să vedeți cum arată „versiunea completă” a paginii, precum și să revizuiți „versiunea doar text”.

18. Utilizarea incorectă a Meta Robots NOINDEX

Problema:

Echipa noastră tehnică SEO a auditat site-urile web și a descoperit că etichetele NOINDEX au fost adăugate la codul sursă al paginilor din greșeală. În plus, paginile văzute care au generat trafic istoric, având o etichetă NOINDEX.

În mod surprinzător, o problemă care se poate întâmpla mai des decât ați crede este că dezvoltatorii împing mediile de realizare live cu eticheta NOINDEX încă prezentă în codul sursă.

În cele din urmă, eticheta NOINDEX va spune motoarele de căutare să nu indexeze pagina și va împiedica afișarea paginii în rezultatele căutării.

Soluţie:

Dacă întâlniți pagini care au o etichetă NOINDEX în loc atunci când auditați un site web și nu este clar de ce este aplicată eticheta, atunci verificați cu echipa de dezvoltare pentru a vedea când și de ce acele pagini includ eticheta.

Dacă o etichetă NOINDEX a fost adăugată din greșeală, atunci ar trebui să le ceri dezvoltatorilor să actualizeze codul sursă și să elimine complet eticheta sau să o actualizeze pentru a citi <meta name="robots” content=" INDEX, FOLLOW">

19. Soft 404 Pagini

Problema:

O pagină soft 404 nu ar trebui să existe pe un site web, se întâmplă atunci când o pagină inexistentă care ar trebui să returneze un cod de stare 404 returnează un cod de stare 200 OK. Dacă 404 pagini returnează un cod de stare 200, ele pot fi accesate cu crawlere și indexate.

Aceasta este, în cele din urmă, o problemă, deoarece motoarele de căutare, cum ar fi Google, pot pierde timpul cu accesarea cu crawlere a acestor pagini, care nu oferă nicio valoare, irosind bugetul de accesare cu crawlere în loc să se concentreze pe pagini valoroase. Aceste pagini pot crea, de asemenea, probleme duplicate pe un site web, mai ales dacă un site web are 1.000 de pagini soft 404 care arată un mesaj „pagină negăsită”.

Există câteva moduri diferite de a găsi pagini soft 404, care includ:

Vizitând Search Console, unde semnalează 404 pagini soft

Vă accesați cu crawlere site-ul și căutați 200 de pagini de cod de stare cu etichete de titlu „Pagină nu a fost găsită”

Accesarea cu crawlere a site-ului dvs. web cu o extracție personalizată care caută mesajul de copiere care este prezent pe paginile de cod de stare 404 și orice pagină de cod de stare de 200 cu acel mesaj ar trebui să fie un 404 soft.

Soluţie:

Dacă întâlniți pagini soft 404 pe site-ul dvs., există câteva soluții care pot fi implementate, acestea includ:

301 redirecționează soft 404 pagini către o pagină alternativă adecvată, dacă este disponibilă

Schimbați codul de stare al acestor pagini într-un cod de stare 404 sau 410, dar verificați dacă nu se va pierde nicio valoare a link-ului.

Dacă vă confruntați cu probleme cu site-ul dvs. sau aveți nevoie de un audit tehnic SEO, vă rugăm să vizitați pagina noastră de servicii tehnice SEO pentru mai multe informații despre cum vă poate ajuta Semetrical.