Dezvoltare web pentru SEO: Un altul aproape că merge spre sud

Ultima actualizare pe 14 septembrie 2018

Acesta este motivul pentru care aveți o companie SEO, așa! Companie, pentru a prinde și corecta ce nu merge bine cu reproiectarea unui site web existent. După cum știe oricine care lucrează în industria de marketing pe internet și a trecut printr-o reconstrucție a unui site web funcțional, o multitudine de lucruri pot merge prost. Recent, un client PPC (plată pe clic) și SEO (optimizare pentru motoarele de căutare) tocmai a terminat cu reconstrucția site-ului lor și a fost lansat fără a permite revizuirea. Această ultimă reconstrucție a site-ului acestui client a mers îngrozitor de greșit la lansare, așa că voi atinge câteva dintre lucrurile așteptate și neașteptate care pot și pot intra în conflict.

Necesitatea

Acest client a achiziționat o afacere existentă care avea un site web de comerț electronic și informațional și era lider în industria lor. Dezvoltatorul web nu a venit cu achiziția. Dintr-un motiv care nu mi-a fost dezvăluit niciodată, clientul nu a putut actualiza nicio pagină din afara coșului de cumpărături. Coșul de cumpărături nu a fost adaptat pentru dispozitive mobile și am putut vedea diferența dintre conversiile lor față de desktop versus mobil. Conversiile mobile au fost practic inexistente. Majoritatea covârșitoare a vânzărilor lor online au fost generate de căutare organică pe desktop, PPC, vizite directe și de recomandare.

Multe dintre elementele necesare pentru a-și îmbunătăți SEO, pur și simplu nu erau acolo. Nu există posibilitatea de a schimba metadatele, etichetele h1, etichetele alt/title etc. Majoritatea acestor date erau generate programatic; precum și meniurile și structura de navigare. Acest nou site ar trebui, de asemenea, să fie securizat. Pe scurt, ceea ce aveau nevoie era un nou site web prietenos pentru dispozitive mobile, securizat și un coș de cumpărături cu un conector pentru a lucra cu suita lor de software de planificare a resurselor întreprinderii (ERP) existentă.

Misiunea

Acest client a avut 3.766 de cuvinte cheie cu rezultate de clasare în primele o sută de SERP-uri Google. Cinci sute treizeci și opt (538) de cuvinte cheie cu rezultate în pagina 1, având un volum mediu lunar de căutare de 65.790 și 43 de cuvinte cheie ocupând poziția unu în SERP-urile Google, care au avut un volum mediu lunar de căutare de 6.110. Sarcina mea a fost să îi ghidez prin cerințele pe care un nou sistem de administrare ar trebui să le ofere pentru a putea implementa SEO în viitor. Aceasta a inclus și protejarea rezultatelor lor existente în clasament cât mai bine posibil.

Selectia

În cele din urmă, clientul a ales un furnizor offshore care ar putea asigura integrarea între software-ul ERP existent și o soluție și un site web nou, prietenos cu dispozitivele mobile și sigure pentru coșul de cumpărături. Nefiind familiarizat cu acest furnizor offshore, clientul mi-a oferit o demonstrație de produs înregistrată pentru a confirma că sistemul de administrare va oferi ceea ce avem nevoie pentru a implementa SEO. După revizuirea demo-ului, am ajuns la concluzia că avem elementele necesare pentru a ajuta clientul cu îmbunătățiri SEO. Am putea crea propriile noastre titluri de pagină, meta descrieri și etichete h1. Am putea actualiza codul Google Analytics (GA), din care rulau cod GA vechi, învechit și nici un cont Search Console. Am avut acces la imagini pentru a adăuga text alt/titlu formatat corespunzător. După cum am aflat mai târziu, și mult prea târziu, a existat chiar și posibilitatea de a aplica redirecționarea 301 chiar pe fiecare pagină. Dar asta este doar o parte din poveste.

Rezultatul

După cum se dovedește, dezvoltatorul a furnizat un șablon, coș de cumpărături și integrare ERP. Clientul a fost însărcinat cu mutarea conținutului (copiere conținut vechi de site și lipire într-o pagină nouă în sistemul de administrare), inclusiv metadatele existente. De asemenea, aceștia au fost însărcinați să introducă adresele URL ale vechiului site în datele noii pagini, pagină cu pagină. Se pare că acest lucru a fost complicat de faptul că clientul nu a putut copia și lipi adresele URL ale vechiului site intacte. Clientul a luat acest lucru drept procedură operațională standard și nu a notificat pe nimeni despre acest lucru. Am recomandat inițial dezvoltatorului să creeze un fișier de redirecționare 301 adecvat. Cronologia de lansare nu a permis clientului să ne permită să verificăm funcționarea corectă. Tocmai l-au lansat și acolo totul a mers prost.

După ce am observat că site-ul reconstruit a fost lansat, am început să testăm manual rezultatele inițiale de clasare a cuvintelor cheie în raport cu rezultatele actuale de clasare. Doar pentru a vedea cum arăta noul site și că toate datele au fost transferate. Toate rezultatele de clasare din SERP-urile Google care erau încă în vigoare au dus la un cod de răspuns 404, cu excepția paginii de pornire. După cum se dovedește, adresele URL ale vechiului site au fost create cu extensii .html, iar noile adrese URL nu. Sistemul de administrare pur și simplu nu a permis ca vechea adresă URL să fie inserată în câmpul de redirecționare 301 furnizat, astfel încât clientul a lipit vechiul URL fără extensia .html. Clientul a presupus că aceasta era o procedură de operare standard.

După multe discuții interne, am descoperit că, dacă eliminați extensia .html, paginile vor redirecționa corect către versiunea securizată a noii adrese URL, în majoritatea cazurilor. Cu toate acestea, în unele cazuri, vechea adresă URL, fără extensia .html, va redirecționa către o adresă URL nouă, care nu este prietenoasă cu motorul de căutare, care conține un șir de interogare pe care nu l-am văzut niciodată înainte. În urma unei examinări suplimentare, am constatat că această adresă URL nouă, necunoscută, era generată de navigarea în meniul principal. Deci, am avut o redirecționare unu la unu, în cele mai multe cazuri, de la vechea adresă URL, extensia .html eliminată, la noua adresă URL prietenoasă pentru motorul de căutare securizat și am putut naviga la același conținut din navigarea principală care a generat noul non -URL prietenos.

Conținut duplicat? Ei bine, ați plasat eticheta rel= canonical, vă puteți întreba? Corect? Nu. Eticheta rel=canonical de pe adresa URL redirecționată prietenoasă cu motorul de căutare a fost setată să trimită către noua adresă URL care nu este prietenoasă cu motorul de căutare care conține șirul de interogare. Examinând eticheta rel=canonical a paginii neprietenoase, am descoperit că această etichetă face referire la o adresă URL complet diferită. Unul care conține categoria și nu șirul de interogare. Deci, o bucată de conținut a fost afișată pentru trei adrese URL diferite, cu etichete rel=canonical setate incorect.

Apoi, am constatat că toți roboții au fost interziși în fișierul robots.txt. Apoi am verificat activitatea în GA. Clientul încă primea vizite din toate sursele, dar nu înregistra conversii. În plus, clientul a dorit ca noi să împingem accesul cu crawlere și indexare, care necesită Search Console de la Google. Problema aici este că codul GA existent era vechi și nu a fost niciodată plasat un cod de verificare Search Console pe site. Acesta este unul dintre acele elemente pe care clientul nu le-a putut schimba din motive niciodată dezvăluite.

Din fericire, clientul a acceptat recomandarea noastră de a implementa actualizarea codului GA la cea mai recentă versiune. Pe cont propriu, au adăugat și managerul de etichete Google. Hopa! Posibil declanșarea dublă a codului GA? Cu Managerul de etichete Google și codul GA asincron actualizat, am putut crea un cont Search Console nou, securizat (https vs. http) pentru client, apoi am descoperit că nu există un sitemap .xml de trimis pentru accesarea cu crawlere solicitată. .

La notificare, clientul a comunicat cu dezvoltatorul și i s-au oferit două adrese URL de sitemap .xml. Unul a funcționat. Unul nu a făcut-o. Cel de lucru avea o intrare care indica harta site-ului .xml care nu funcționează. Harta site-ului .xml care nu funcționează nu avea formatarea adecvată atunci când a fost vizualizată într-un browser. Prin urmare, nu am trimis sitemap-ul .xml furnizat la momentul respectiv.

Rezultatul Final

Am anunțat clientul, prin e-mailuri etapizate, despre ceea ce găsim. În primul rând, problema redirecționărilor eșuate și am constatat că, dacă am eliminat extensia .html, acestea au redirecționat corect. Clientul a notificat dezvoltatorul, iar dezvoltatorul a răspuns că nu puteți pune extensia .html în instrumentul de redirecționare 301 furnizat. Descoperirea ulterioară a relevat faptul că clientul a descoperit acest lucru și a crezut că aceasta este o procedură de operare standard.

Din anumite motive, site-ul web inițial a fost șters (oops mare aici, aveți întotdeauna o versiune funcțională pregătită pentru a reveni) așa că nu am putut extrage niciuna dintre vechile URL-uri pentru a crea o nouă redirecționare permanentă 301 prin fișierul .htaccess. Rezoluția a fost de a crea o potrivire unu-la-unu nouă, adresă URL veche versus adresă URL nouă, foaie de calcul, trăgând datele paginii de destinație din Google Analytics pentru ultimul an, pentru ca dezvoltatorul să creeze o redirecționare care funcționează corect, care înlocuiește redirecționarea 301 în sistem de administrare care a fost însărcinat clientului.

Problema rezolvata contra cost suplimentar pentru client de la dezvoltator. Orice rezultate vechi de clasare existente cu o extensie .html au început să fie redirecționate corect și, în decurs de 14 zile, rezultatele de clasare au fost înlocuite cu noile adrese URL securizate și, în cea mai mare parte, foarte aproape de rezultatul de clasare preexistent. Problema etichetei rel=canonical a fost rezolvată într-o întâlnire online cu agentul de vânzări al dezvoltatorului web și s-a rezumat la o eroare de introducere a utilizatorului. Au existat mai multe câmpuri în care datele puteau fi introduse sau selectate dintr-o alegere existentă, iar soluția necesita resetarea acestor câmpuri și ștergerea cache-ului.

Cele două versiuni suplimentare ale adresei URL prietenoase și sigure au dispărut imediat. În ceea ce privește botul /disallow din robots.txt, la notificare, dezvoltatorul a rezolvat rapid această problemă.

S-a constatat că problema cu datele de conversie GA pare a fi izolată de furnizorul de servicii comerciant al clientului; care era nou și diferit de vechiul furnizor. Nimeni nu s-a gândit să comunice furnizorului de servicii comerciant că avem nevoie de cod GA pe pagina lor de finalizare a achiziției pentru a furniza datele necesare despre comerțul electronic de care clientul are nevoie pentru a lua decizii de afaceri informate cu privire la eforturile lor de marketing. Nu am fost informați despre existența unui nou furnizor de servicii pentru comercianți.

În cele din urmă, am creat manual un fișier .xml sitemap pe care doream să îl încărcăm pe server și am cerut dezvoltatorului să dezactiveze orice crează sitemap-ul .xml care nu funcționează. Într-o discuție ulterioară cu agentul de vânzări al dezvoltatorului, ni s-a spus că nu putem încărca un alt sitemap .xml pe server.

După ce i-a arătat agentului de vânzări al dezvoltatorului rezultatele, el a declarat că se va uita la ele, dar ne-a sugerat să vedem codul sursă. La vizualizarea în codul sursă, documentul .xml a fost formatat corespunzător. După ce am văzut acest rezultat, am anunțat Google, prin Search Console, că avem de fapt un sitemap .xml funcțional. În cele din urmă, pe parcursul mai multor zile, Google a înregistrat în sfârșit că aveam un sitemap .xml funcțional și a început să afișeze adresele URL care sunt indexate. Cu toate acestea, așa cum sa menționat anterior, sitemap-ul .xml formatat corect avea doar o singură intrare care indică către sitemap-ul .xml suplimentar care nu s-ar rezolva într-un browser, dar era afișat corect în codul sursă.

Ei bine, această problemă s-a transformat într-o problemă mai mare, deoarece sitemap-ul suplimentar .xml a generat un cod de răspuns de 500, așa că există o problemă cu accesarea agentului Google în această zonă a site-ului. Și, începând de astăzi, ambele sitemap-uri .xml generează 500 de coduri de răspuns. Cu o săptămână înainte, am solicitat o accesare cu crawlere folosind instrumentul de preluare, redare, trimitere disponibil pentru noi în Google Search Console, care credem că a cauzat accesarea cu crawlere și indexarea noului site.

Deci, în încheiere, dacă poate merge prost, atunci când vă reconstruiți site-ul web și sperăm că veți putea evita unele dintre aceste greșeli. Blocarea roboților din fișierul robots.txt și redirecționarea incorectă vă pot scoate din afaceri online sau, cel puțin, vă pot pune în pericol. Dacă roboții nu pot accesa cu crawlere site-ul dvs., veți renunța în cele din urmă din index și atunci când veți renunța din index, cu excepția cazului în care provin din surse de recomandare, directe sau alte surse non-organice, majoritatea vizitelor de căutare organică vor deveni inexistente.

Dacă rezultatele nu redirecționează corect, vizitatorii organici pot vedea site-ul dvs. ca nedemn de încredere. Clienții existenți care au site-ul dvs. salvat ca marcaj pot deveni frustrați atunci când marcajul lor nu este redirecționat corect. Ca să nu mai vorbim că a trebuit să le închidem campania PPC între timp. Făcând clic pe un anunț plătit și obținerea unui răspuns de 404 pagini negăsit, nu este doar frustrant pentru vizitatori, ci este și costisitor! Click-ul te costă bani și nu obții nicio rentabilitate a investiției tale. Și de aceea ne ai pe noi.

– Mark Gray, Senior SEO Manager