Sitemap

Greșeli de reproiectare a site-ului web care distrug SEO

Reproiectarea unui site web, fie că este al tău sau al unui client, este o parte esențială a marketingului de astăzi.Este esențial deoarece tehnologia, tendințele și așteptările utilizatorilor se schimbă în timp și, dacă vrem să rămânem competitivi, trebuie să ținem pasul cu aceste schimbări.

Dar această sarcină, deși esențială, prezintă și anumite riscuri din perspectiva SEO.O serie de lucruri pot merge prost în timpul procesului.Aceste probleme pot determina motoarele de căutare să nu mai vadă acel site web ca răspunsul autorizat la întrebările relevante.În unele cazuri, anumite greșeli pot duce chiar la penalități.

Nimeni nu vrea asta.

Deci, în acest articol, vom explora câteva dintre greșelile comune de design web care pot distruge SEO.Cunoașterea riscurilor potențiale vă poate ajuta să evitați tipul de greșeli care vă limitează traficul de căutare organic.

Lăsând mediul de dezvoltare accesabil cu crawlere/indexabil

Oamenii gestionează mediile de dezvoltare în multe moduri diferite.Majoritatea pur și simplu configurează un subdosar sub domeniul lor.Unii pot crea un domeniu strict pentru dezvoltare.Apoi sunt cei care iau genul de precauții pentru a-și ascunde mediul de dezvoltare care ar da unui agent CIA o senzație caldă și neclară în acel loc gol unde ar trebui să fie inima lor.

Tind să mă încadrez în această din urmă categorie.

Motoarele de căutare vor urma, în general, link-uri și vor indexa conținutul pe care îl găsesc pe parcurs – uneori chiar și atunci când le spui în mod explicit să nu facă.Acest lucru creează probleme, deoarece ar putea indexa două versiuni ale aceluiași site web, ceea ce poate cauza probleme atât cu conținutul, cât și cu linkurile.

Din această cauză, pun cât mai multe blocaje posibil în calea motoarele de căutare care încearcă să acceseze mediul meu de dezvoltare.

Iată ce fac.Primul pas este să utilizați o adresă URL curată care nu a mai fost folosită niciodată pentru un site web live.Acest lucru asigură că nu există legături care să trimită către acesta.Apoi, interziceți toți roboții care folosesc robots.txt și configurați o pagină de index goală, astfel încât alte foldere să nu fie vizibile.În trecut, am mers chiar și până la configurarea protecției prin parolă, dar în majoritatea cazurilor, asta poate fi exagerat.Puteți efectua acel apel.

De acolo, voi configura un folder separat pentru fiecare site web în dezvoltare.De obicei, numele folderului va fi o combinație de cuvinte incomplete, astfel încât este puțin probabil să fie găsit la întâmplare.WordPress va fi apoi instalat în aceste foldere și configurat să blocheze și roboții la acest nivel.

Schimbarea arbitrară a numelor imaginilor pe paginile care se clasează bine

Aceasta nu este întotdeauna o problemă, dar dacă o pagină web se clasifică bine, schimbarea numelui unei imagini de pe pagina respectivă poate provoca o pierdere a clasamentului.Mai ales dacă designerul web nu știe ce fac.

Am văzut că acest lucru se întâmplă de mai multe ori, când un client angajează un designer web care nu înțelege SEO pentru a reproiecta un site web care este deja bine clasat.Ca parte a procesului de reproiectare, ei înlocuiesc imaginile vechi cu imagini noi, mai mari, dar, lipsind experiența corespunzătoare, folosesc nume stupide de imagini care oferă valoare SEO zero, cum ar fi image1.jpg.

Acest lucru elimină o parte vitală de context pe care motoarele de căutare o folosesc pentru a determina unde ar trebui să se claseze o anumită pagină web.

Ștergerea paginilor sau modificarea adreselor URL ale paginilor fără a le redirecționa

În timpul unei reproiectări, unele pagini aproape sigur nu vor mai fi necesare.Designerii web mai puțin experimentați le vor șterge adesea pur și simplu.Alte pagini pot fi mutate și/sau redenumite, ceea ce, în majoritatea cazurilor, le modifică adresa URL.În aceste cazuri, designerii web fără experiență schimbă adesea aceste adrese URL și consideră sarcina finalizată.

Aceasta este o mare greșeală, deoarece unele dintre acele pagini s-ar putea să fie deja bine clasate.Este posibil să aibă legături de intrare care să indice către ei sau să fi fost marcate de vizitatori.

Când ștergeți pagini care au deja linkuri de intrare, veți pierde toată valoarea SEO de la acele linkuri.În unele cazuri, acest lucru poate duce la o pierdere drastică a clasamentului.

Problema merge și mai profund, totuși.Oricine face clic pe acele linkuri sau marcaje va fi întâmpinat de o pagină 404.Acest lucru prezintă valoare zero pentru oricine și, mai important, creează o experiență negativă pentru utilizator.Acest lucru este important deoarece Google a confirmat că experiența utilizatorului este un factor de clasare.

Modul corect de a șterge pagini este să le redirecționați către cea mai relevantă pagină care există în prezent.În ceea ce privește mutarea paginilor, care include orice modificare în vreun fel adresa URL a acelei pagini, este la fel de important să redirecționați vechea adresă URL la cea nouă.

În ambele scenarii, în general, ar trebui utilizată o redirecționare 301.Aceasta le spune motoarelor de căutare că vechea pagină a fost mutată definitiv în noua locație.Pentru majoritatea platformelor de găzduire, acest lucru se realizează cel mai bine prin adăugarea intrării corespunzătoare în fișierul dvs. .htaccess.

Dacă nu puteți vedea un fișier .htaccess pe serverul dvs., poate fi necesar să ajustați setările programului dvs. FTP pentru a vedea fișierele ascunse.

Unele platforme de găzduire specializate pot utiliza o metodă diferită, așa că poate fi necesar să verificați cu echipa lor de asistență pentru a determina cum să o realizați.

Nu se efectuează o accesare completă cu crawlere după migrarea către și dinspre mediul de dezvoltare

Indiferent de metoda pe care o utilizați pentru migrare, sunteți obligat să întâlniți unele erori.De obicei, mai întâi veți migra site-ul web live în mediul dvs. de dezvoltare, apoi, mai târziu, îl veți trimite înapoi la serverul live după ce ați făcut și testat modificările.

Unul pe care îl întâlnesc frecvent sunt linkurile din conținutul care indică locul greșit.De exemplu, într-o pagină sau postare pe site-ul web live, este posibil să aveți un link care indică:

domain.com/services/

Odată migrat în mediul de dezvoltare, acesta poate fi:

devdomain.com/client123/services/

Totul este bine și bine până acum, nu?

Dar uneori, în timpul migrării site-ului web finalizat înapoi pe serverul live, conținutul din pagini și postări poate conține în continuare link-uri care indică paginile din mediul de dezvoltare.

Acesta este doar un exemplu.Există nenumărate link-uri către conținut dintr-un site web - inclusiv link-uri către imaginea esențială, fișierele JavaScript și CSS.

Din fericire, soluția este simplă.Un instrument precum Screaming Frog, care rulează de pe desktop, sau un instrument bazat pe cloud precum SEMrush, poate fi folosit pentru a accesa cu crawlere fiecare link din site-ul dvs.Acestea includ linkurile text vizibile pe front end, precum și toate linkurile către fișierele imagine, JavaScript și CSS care sunt ascunse în HTML-ul unui site web.

Asigurați-vă că examinați toate linkurile către surse externe odată ce noul site web a fost migrat pe serverul live, deoarece orice linkuri care indică mediul dvs. de dezvoltare vor apărea ca linkuri externe - când găsiți „linkuri externe” care ar trebui să fie într-adevăr link-uri interne, puteți face corecturile corespunzatoare.

Acest pas este esențial după migrarea în ambele direcții, pentru a preveni erorile potențial catastrofale.

Eșecul de a efectua o verificare completă a funcției pe toate

Odată ce un site web reproiectat a fost migrat pe serverul live, trebuie să faceți mai mult decât să revizuiți rapid câteva pagini pentru a vă asigura că lucrurile arată bine.În schimb, este esențial să testați fizic totul pentru a vă asigura că nu numai că arată corect, ci și funcționează corect.

Aceasta include:

  • Formulare de contact.
  • Funcționalitate de comerț electronic.
  • Capabilitati de cautare.
  • Instrumente interactive.
  • Playere multimedia.
  • Analytics.
  • Verificare Google Search Console / Bing Webmaster Tools.
  • Urmărirea pixelilor.
  • Reclame dinamice.

Eșecul de a reconfigura WordPress și pluginurile după migrarea la serverul live

Îți amintești cum am vorbit despre importanța de a construi un zid între mediul tău de dezvoltare și crawlerele motoarelor de căutare?Ei bine, este și mai important să dărâmați acel zid după migrarea site-ului web pe serverul live.

Nu reușiți să faceți acest lucru este ușor.Este, de asemenea, devastator.De fapt, este o greșeală pe care am făcut-o acum câțiva ani.

După ce am migrat site-ul web al unui client pe serverul său live, am uitat să debifez caseta din Yoast SEO care le spunea motoarele de căutare să nu îl acceseze cu crawlere sau să-l indexeze.Din păcate, nimeni nu a observat timp de câteva zile, moment în care, site-ul web fusese aproape complet eliminat din indexul Google.Din fericire, nu s-au bazat pe trafic organic și, odată ce am debifat această casetă, site-ul a fost rapid reindexat.

Din cauza impactului pe care îl pot avea astfel de greșeli, este esențial ca, după migrarea la serverul live, să verificați imediat configurația WordPress, precum și orice pluginuri care ar putea afecta modul în care motoarele de căutare tratează site-ul dvs.

Aceasta include pluginuri pentru:

  • SEO.
  • Redirecționare.
  • Sitemaps.
  • Schemă.
  • Memorarea în cache.

Neglijând să acordați atenție detaliilor

Niciuna dintre aceste greșeli nu este deosebit de complicată sau dificil de evitat.Trebuie pur și simplu să fii conștient de ele, să implementezi un plan pentru a le evita și să fii atent la detalii.

Opiniile exprimate în acest articol sunt cele ale autorului invitat și nu neapărat Search Engine Land.Autorii personalului sunt enumerați aici.