Sviluppo Web per SEO: un altro quasi va a sud

Ultimo aggiornamento il 14 settembre 2018

Questo è il motivo per cui hai un'azienda SEO, come quella! Company, per cogliere e correggere ciò che non va nella riprogettazione di un sito web esistente. Come sa chiunque lavori nel settore del marketing su Internet e sia passato attraverso la ricostruzione di un sito Web funzionante, una miriade di cose possono andare storte. Di recente, un client PPC (pay per click) e SEO (ottimizzazione dei motori di ricerca) ha appena terminato la ricostruzione del proprio sito Web e avviato senza consentirne la revisione. Questa ultima ricostruzione del sito di questo client è andata terribilmente storta al lancio, quindi toccherò alcune delle cose attese e inaspettate che possono e potrebbero andare in conflitto.

L'esigenza

Questo cliente ha acquistato un'azienda esistente che disponeva di un sito Web informativo e di e-commerce esistente ed era leader nel proprio settore. Lo sviluppatore web non è venuto con l'acquisto. Per qualche motivo mai rivelato a me, il cliente non è stato in grado di aggiornare nessuna pagina al di fuori del carrello. Il carrello degli acquisti non era ottimizzato per i dispositivi mobili e abbiamo potuto notare la differenza nelle loro conversioni da desktop rispetto a dispositivi mobili. Le conversioni da dispositivi mobili erano praticamente inesistenti. La stragrande maggioranza delle loro vendite online è stata generata da ricerche organiche desktop, PPC, visite dirette e referral.

Anche molti degli elementi necessari per migliorare la loro SEO non erano presenti. Nessuna possibilità di modificare metadati, tag h1, tag alt/title, ecc. La maggior parte di questi dati veniva generata a livello di codice; così come i menu e la struttura di navigazione. Anche questo nuovo sito dovrebbe essere sicuro. In breve, ciò di cui avevano bisogno era un nuovo sito Web sicuro e mobile friendly e un carrello della spesa con un connettore per funzionare con la suite software ERP (Enterprise Resource Planning) esistente.

La missione

Questo client aveva 3.766 parole chiave con risultati di ranking nelle prime cento SERP di Google. Cinquecentotrentotto (538) parole chiave con risultati di pagina 1, con un volume di ricerca mensile medio di 65.790 e 43 parole chiave che si classificano al primo posto nelle SERP di Google che avevano un volume di ricerca mensile medio di 6.110. Il mio compito era guidarli attraverso i requisiti che un nuovo sistema di amministrazione avrebbe dovuto fornire per poter implementare la SEO andando avanti. Ciò includeva anche la protezione dei risultati delle classifiche esistenti nel miglior modo possibile.

La selezione

Il cliente ha infine selezionato un fornitore offshore in grado di fornire l'integrazione tra il software ERP esistente e una nuova soluzione di carrello degli acquisti sicura e mobile friendly e un sito Web. Non avendo familiarità con questo fornitore offshore, il cliente mi ha fornito una demo del prodotto registrata per confermare che il sistema di amministrazione avrebbe fornito ciò di cui avevamo bisogno per implementare la SEO. Dopo aver esaminato la demo, ho concluso che avevamo gli elementi necessari per assistere il cliente con miglioramenti SEO. Potremmo creare i nostri titoli di pagina, meta descrizioni e tag h1. Potremmo aggiornare il codice di Google Analytics (GA), di cui stavano eseguendo un codice GA vecchio e obsoleto e nessun account Search Console. Abbiamo avuto accesso alle immagini per aggiungere testo alternativo/titolo correttamente formattato. Come abbiamo scoperto in seguito, e troppo tardi, c'era persino la possibilità di applicare il reindirizzamento 301 direttamente su ogni pagina. Ma questa è solo una parte della storia.

Il risultato

A quanto pare, lo sviluppatore ha fornito un modello, un carrello degli acquisti e un'integrazione ERP. Il cliente aveva il compito di spostare il contenuto (copiando il vecchio contenuto del sito e incollandolo in una nuova pagina nel sistema di amministrazione), compresi i metadati esistenti. Avevano anche il compito di inserire gli URL del vecchio sito nei dati della nuova pagina, pagina per pagina. Si scopre che ciò era complicato dal fatto che il client non poteva copiare e incollare intatti gli URL del vecchio sito. Il cliente l'ha presa come procedura operativa standard e non ne ha informato nessuno. Inizialmente avevamo raccomandato allo sviluppatore di creare un file di reindirizzamento 301 appropriato. La sequenza temporale di implementazione non ha consentito al cliente di consentirci di esaminarne il corretto funzionamento. L'hanno appena lanciato ed è lì che è andato tutto storto.

Dopo aver notato che il sito ricostruito era stato lanciato, abbiamo iniziato a testare manualmente i risultati del ranking delle parole chiave originali rispetto ai risultati del ranking attuale. Solo per vedere che aspetto aveva il nuovo sito e che tutti i dati sono stati trasferiti. Tutti i risultati del ranking nelle SERP di Google che erano ancora in vigore hanno prodotto un codice di risposta 404 ad eccezione della home page. A quanto pare, gli URL del vecchio sito sono stati creati con estensioni .html e i nuovi URL non lo erano. Il sistema di amministrazione semplicemente non consentiva di incollare il vecchio URL nel campo di reindirizzamento 301 fornito, quindi il client ha incollato il vecchio URL senza l'estensione .html. Il cliente aveva ipotizzato che si trattasse di una procedura operativa standard.

Dopo molte discussioni interne, abbiamo scoperto che se rimuovevi l'estensione .html, le pagine reindirizzavano correttamente alla versione sicura del nuovo URL, nella maggior parte dei casi. Tuttavia, in alcuni casi, il vecchio URL, senza l'estensione .html, reindirizzava a un nuovo URL molto non compatibile con i motori di ricerca contenente una stringa di query che non avevamo mai visto prima. In un ulteriore esame, abbiamo scoperto che questo nuovo URL sconosciuto veniva generato dalla navigazione nel menu principale. Quindi abbiamo avuto un reindirizzamento uno a uno, nella maggior parte dei casi, dal vecchio URL, estensione .html rimossa, al nuovo URL sicuro per i motori di ricerca e siamo stati in grado di navigare allo stesso contenuto dalla navigazione principale che ha generato il nuovo non -URL amichevole.

Contenuti duplicati? Bene, potresti chiedere il tag rel= canonical è stato inserito? Correttamente? No. Il tag rel=canonical sull'URL reindirizzato adatto ai motori di ricerca è stato impostato per puntare al nuovo URL non compatibile con i motori di ricerca contenente la stringa di query. Esaminando il tag rel=canonical della pagina non amichevole, abbiamo scoperto che questo tag faceva riferimento a un URL completamente diverso. Uno contenente la categoria e non la stringa di query. Quindi, un contenuto veniva mostrato per tre URL diversi, con tag rel=canonical impostati in modo errato.

Successivamente, abbiamo scoperto che tutti i bot erano stati disabilitati nel file robots.txt. Quindi abbiamo controllato l'attività in GA. Il cliente continuava a ricevere visite da tutte le fonti, ma registrava zero conversioni. Inoltre, il cliente voleva che spingessimo la scansione e l'indicizzazione che richiedono la Search Console di Google. Il problema qui è che il codice GA esistente era vecchio e non è mai stato inserito un codice di verifica di Search Console sul sito. Questo è uno di quegli elementi che il cliente non ha potuto modificare per ragioni mai rivelate.

Fortunatamente, il cliente ha seguito la nostra raccomandazione di implementare l'aggiornamento del codice GA all'ultima versione. Da soli hanno anche aggiunto il tag manager di Google. Ops! Possibile doppia cottura del codice GA? Con Google Tag Manager e il codice GA asincrono aggiornato, siamo stati in grado di creare un nuovo account Search Console sicuro (https rispetto a http) per il client, ma abbiamo scoperto che non c'era una mappa del sito .xml da inviare per una scansione richiesta .

Dopo la notifica, il client ha comunicato con lo sviluppatore e gli sono stati forniti due URL della mappa del sito .xml. Uno ha funzionato. Uno no. Quello funzionante aveva una voce che puntava alla mappa del sito .xml non funzionante. La mappa del sito .xml non funzionante non aveva la formattazione corretta quando visualizzata in un browser. Quindi non abbiamo inviato la mappa del sito .xml fornita in quel momento.

Il risultato finale

Abbiamo informato il cliente, tramite e-mail in scena, di ciò che stavamo trovando. Innanzitutto, il problema dei reindirizzamenti non riusciti e che abbiamo riscontrato che se avessimo rimosso l'estensione .html, avrebbero reindirizzato correttamente. Il client ha informato lo sviluppatore e lo sviluppatore ha risposto che non è stato possibile inserire l'estensione .html nello strumento di reindirizzamento 301 fornito. Ulteriori scoperte hanno rivelato che il cliente lo aveva scoperto e pensava che questa fosse una procedura operativa standard.

Per qualche motivo, il sito web originale è stato cancellato (grande oopsy qui, ho sempre una versione funzionante pronta per ripiegare) quindi non abbiamo potuto estrarre nessuno dei vecchi URL per creare un nuovo reindirizzamento 301 permanente tramite il file .htaccess. La risoluzione era di creare una nuova corrispondenza uno a uno, vecchio URL e nuovo URL, foglio di calcolo, estraendo i dati della pagina di destinazione da GA per l'anno passato, affinché lo sviluppatore creasse un reindirizzamento correttamente funzionante che sovrascrive il reindirizzamento 301 nel sistema di amministrazione che è stato affidato al client.

Problema risolto con un costo aggiuntivo per il cliente dallo sviluppatore. Tutti i vecchi risultati di ranking esistenti con un'estensione .html hanno iniziato a reindirizzare correttamente ed entro 14 giorni i risultati di ranking sono stati sostituiti con i nuovi URL sicuri e, per la maggior parte, molto vicini al risultato di ranking preesistente. Il problema del tag rel=canonical è stato risolto in una riunione online con l'agente di vendita dello sviluppatore web ed è stato causato da un errore di input dell'utente. C'erano diversi campi in cui i dati potevano essere inseriti o selezionati da una scelta esistente e la soluzione richiedeva di reimpostare questi campi e svuotare la cache.

Le due versioni aggiuntive dell'URL amichevole e sicuro sono immediatamente scomparse. Per quanto riguarda il bot /disallow nel file robots.txt, dopo la notifica, lo sviluppatore ha risolto rapidamente questo problema.

È stato riscontrato che il problema con i dati di conversione GA sembra essere isolato per il fornitore di servizi commerciali del cliente; che era nuovo e diverso dal vecchio provider. Nessuno ha pensato di comunicare al fornitore di servizi del commerciante che avevamo bisogno del codice GA sulla loro pagina di pagamento per fornire i dati di e-commerce necessari al cliente per prendere decisioni aziendali informate sui propri sforzi di marketing. Non siamo stati informati dell'esistenza di un nuovo fornitore di servizi commerciali.

Infine, abbiamo creato manualmente un file della mappa del sito .xml che volevamo caricare sul server e abbiamo chiesto allo sviluppatore di disabilitare qualsiasi cosa stesse creando la mappa del sito .xml non funzionante. In un'ulteriore discussione con l'agente di vendita dello sviluppatore, ci è stato detto che non potevamo caricare un'altra mappa del sito .xml sul server.

Dopo aver mostrato i risultati all'agente di vendita dello sviluppatore, ha dichiarato che avrebbe esaminato il problema, tuttavia, ha suggerito di visualizzare il codice sorgente. Durante la visualizzazione nel codice sorgente, il documento .xml è stato formattato correttamente. Dopo aver visto questo risultato, abbiamo informato Google, tramite Search Console, che in effetti avevamo una mappa del sito .xml funzionante. Infine, nel corso di diversi giorni, Google ha finalmente registrato che avevamo una mappa del sito .xml funzionante e ha iniziato a mostrare gli URL indicizzati. Tuttavia, come affermato in precedenza, la mappa del sito .xml formattata correttamente aveva solo una voce che puntava alla mappa del sito .xml aggiuntiva che non sarebbe stata risolta in un browser, ma visualizzata correttamente nel codice sorgente.

Bene, questo problema si è trasformato in un problema più grande poiché la mappa del sito .xml aggiuntiva ha generato un codice di risposta 500, quindi c'è un problema con l'agente di Google che accede a quest'area del sito. E, ad oggi, entrambe le sitemap .xml stanno generando 500 codici di risposta. La settimana prima, avevamo richiesto una scansione utilizzando lo strumento di recupero, visualizzazione e invio a nostra disposizione in Google Search Console che riteniamo abbia causato la scansione e l'indicizzazione del nuovo sito.

Quindi, in chiusura, se può andare storto, lo farà, durante la ricostruzione del tuo sito Web e, si spera, sarai in grado di evitare alcuni di questi errori. Bloccare i bot nel file robots.txt e reindirizzare in modo improprio può metterti fuori mercato online o, almeno, in pericolo. Se i bot non possono eseguire la scansione del tuo sito, alla fine esci dall'indice e quando esci dall'indice, a meno che non provengano da referral, dirette o altre fonti non organiche, la maggior parte delle visite di ricerca organica diventerà inesistente.

Se i risultati non vengono reindirizzati correttamente, i visitatori organici potrebbero visualizzare il tuo sito come non affidabile. I clienti esistenti che hanno il tuo sito salvato come segnalibro possono sentirsi frustrati quando il loro segnalibro a non reindirizza correttamente. Per non parlare del fatto che nel frattempo abbiamo dovuto chiudere la loro campagna PPC. Fare clic su un annuncio a pagamento e ottenere una risposta 404 pagina non trovata non è solo frustrante per i tuoi visitatori, ma è costoso! Il clic ti costa denaro e non ottieni alcun ritorno sul tuo investimento. Ed è per questo che ci hai.

– Mark Gray, Senior SEO Manager