Il problema del passaggio ad HTTPS è che quando si dice "passaggio ad HTTPS" in realtà si dicono più cose assieme, alcune amministrative, altre lato software, altre lato webserver:

• acquisizione di un certificato SSL (wildcard? Solo dominio?)
• installazione del certificato SSL (l'hosting lo supporta?)
• impostazione del software CMS per veicolare contenuti su SSL (e qui si vedono le peggio cose, soprattutto cose che potenzialmente rompono i passaggi successivi)
• revisione dei link interni e dei contenuti veicolati tramite HTTP (ad es. parti del template)
• redirect permanente dei contenuti da HTTP a HTTPS (vedere punto 3)

Sbagli una qualunque minchiata ad uno qualsiasi di questi passaggi e rischi di mandare all'aria tutto.

E questo solo considerando la migrazione e non la manutenzione... vogliamo parlare di siti con il certificato scaduto? O della perdita di visibilità su Google Search Console, dato che ovviamente HTTPS lo vede come un sito nuovo?

Le migrazioni da HTTP a HTTPS possono essere fatte in modo indolore. Ma devi (DEVI) fare tutto giusto.

Ed è un'attività al 100% tecnica che presuppone una buona se non ottima conoscenza del protocollo HTTP e di come i crawler interagiscono con le pagine del sito.

Per fare si può fare, ma non è una cosa che si può fare "schiacciando un pulsante". Se lo fai schiacciando un pulsante, hai buone probabilità di avere fatto cazzate.

la confusione per me è sempre stata quella di leggere "la versione HTTPS" inteso come fosse lo stesso sito in HTTP.
Non possono co-esistere, è un passaggio dove il redirect 301 fa da ponte.

C'è anche un'altra cosa che mi ha sempre confuso, ad esempio il sito con o senza il "www" a prefisso di dominio. Presumo il ragionamento sia lo stesso, se si ritiene più pratico realizzare il proprio sito senza il "www", è utile il redirect 301 (o almeno il rel=canonical come indica Marco).

Portate pazienza se vi ho portato nella SEO di almeno 10 anni fa... per la realizzazione di applicazioni web sono veterano (selezione prodotti, backend, ...), ma nella gestione di contenuti e la loro efficace gestione per un motore di ricerca sono un novellino...

Grazie, ciao

@andyj115 said:

la confusione per me è sempre stata quella di leggere "la versione HTTPS" inteso come fosse lo stesso sito in HTTP.
Non possono co-esistere, è un passaggio dove il redirect 301 fa da ponte.

C'è anche un'altra cosa che mi ha sempre confuso, ad esempio il sito con o senza il "www" a prefisso di dominio. Presumo il ragionamento sia lo stesso, se si ritiene più pratico realizzare il proprio sito senza il "www", è utile il redirect 301 (o almeno il rel=canonical come indica Marco).

Portate pazienza se vi ho portato nella SEO di almeno 10 anni fa... per la realizzazione di applicazioni web sono veterano (selezione prodotti, backend, ...), ma nella gestione di contenuti e la loro efficace gestione per un motore di ricerca sono un novellino...

Grazie, ciao

Secondo le linee guida di Google nella search console andrebbero indicate tutte e tre la versione con senza http e quella https. Già questo dovrebbe impedire di creare contenuto duplicato poi il canonical è un rafforzativo necessario. Il 301 serve quando hai file fisici identici in posizioni diverse esempio in caso di migrazione del sito quando nelle serp compaiono ancora i vecchi risultati (gestisci anche la procedura cambio indirizzo in search console). Nel caso di un sito su Aruba ad esempio hai un unico file pippo html raggiungibile sia con protocollo http che https. In questo caso col canonical dovresti essere a posto.

In generale, niente canonical se puoi fare un 301. E anche sulle versioni:

HTTP piuttosto che HTTPS: sono due siti differenti.

Con WWW e senza WWW: sono due siti differenti.

In generale Google è diventato abbastanza bravo a capire che si tratta di versioni identiche dello stesso sito... ma è una cosa che fa Google NONOSTANTE la nostra cattiva configurazione.

In generale:

• tra HTTP e HTTPS, sceglierne uno (tipicamente il secondo). L'altro fare redirect 301.
• tra WWW e senza WWW, sceglierne uno (tipicamente il primo). L'altro fare redirect 301.

vi chiedo una cosa, per gli esperti di WordPress: dopo aver reindirizzato il database, che quindi punta al nuovo https, il redirect 301 va implementato comunque? non va in automatico?

Cosa intendi con "dopo aver reindirizzato il database"?

Reindicizzato maybe? Effettivamente vedo che l'autocorrettore cambia in reindirizzato.

Grazie Marco, grazie Kal

nono intendo proprio reindirizzato. con wordpress se non procedi a modificare l'htaccess e anche nel database le nuove impostazioni della url da http a https, rischi di lasciare online il sito anche su http, con le conseguenti penalizzazioni. se invece si effettua il passaggio, il sito rimane visitabile solo su https, e WordPress reindirizza automaticamente. chiedevo appunto se fosse sufficiente questo, oltre che segnalare la nuova sitemap (che comunque con gli appositi plugin anche quella va in automatico). grazie!

ciao Lauryn,

di solito passo da CMS proprietari o siti statici a WordPress (ed ultimamente sto guardando GRAV CMS), quindi valuto tutto con un .httaccess dedicato allo scopo (oppure ad un index.php per avere i redirect gestiti da una tabella di MySQL dopo aver fatto un'estrazione delle vecchie pagine dal sito).

Ho trovato invece questo articolo per Wordpress da HTTP a HTTPS

http://seoblog.giorgiotave.it/migrazione-http-https/4861

Spero ti dia una checklist ed una risposta ad i tuoi dubbi

thank you andy!

mi dà errore quel link, me lo passi in privato?

Attivato

grazie giorgio, molto utile, e mi conferma quanto dicevo. con wordpress è tutto molto più semplice. bisogna poi tenere d'occhio google strumenti per webmaster con la nuova sitemap. ok ci sono grazie!

Perchè i problemni "tecnici" devono diventare problemi seo?
Credo sia ovvio che se il programmatore sbagli qualcosa, una qualsiasi non solo l'https, il sito va giù. Leggendo la prima domanda "Ci sono problemi SEO con il passaggio ad HTTPS?" pensavo di trovare una qualche considerazione(ranking) da parte di google.

Mi pare di capire che l'https sia attualmente un buon fattore di posizionamento.

La maggior parte dei problemi SEO sono legati a problemi tecnici.

Quando passi ad HTTPS l'errore che puoi commettere è tecnico per vari motivi.

Lato fattore di ranking HTTPS è sostanzialmente inutile.

@seo-friendly said:

Perchè i problemni "tecnici" devono diventare problemi seo?

Perché ci sono problemi tecnici che non inficiano l'accessibilità del sito da parte degli utenti (il sito funziona), ma causano problemi ai crawler (contenuto duplicato, redirezioni temporanee o errate, etc.).

E qua non c'entra nulla il ranking, ma proprio l'indicizzazione dei contenuti.

E sul fatto che HTTPS possa essere un fattore di ranking... ammesso e non concesso che lo sia (ci sono opinioni contrastanti sulla cosa), nel momento in cui la maggior parte dei siti di una certa dimensione adotta HTTPS, il fattore di ranking di fatto cessa di avere peso. E' un dibattito più che sterile: è un dibattito già vecchio.

Vedi ad esempio: troyhunt.com/https-adoption-has-reached-the-tipping-point

@Juanin said:

La maggior parte dei problemi SEO sono legati a problemi tecnici.

Quando passi ad HTTPS l'errore che puoi commettere è tecnico per vari motivi.

Lato fattore di ranking HTTPS è sostanzialmente inutile.

Perchè qui dice il contrario? searchmetrics.com/knowledge-base/ranking-factors-infographic-2016/

@seo-friendly perché per farla breve i Fattori di Ranking di Searchmetrics non sono affatto fattori di ranking.

Sono al meglio correlazioni di alcuni fattori con il ranking e al peggio risultati di un sondaggio su cosa gli operatori del settore **pensano **siano i fattori di ranking. In altre parole, quello che in america chiamano "circlejerk", un gigantesco giro di opinioni senza fondamento che si rinforzano a vicenda.

Chi ha fatto **per davvero **una migrazione su HTTPS ti potrà confermare che l'effetto sulla posizione media dopo la migrazione è pressoché nullo.

I Fattori di Ranking sono da bandire nel 2017 (lo erano anche anni fa). Niente giudizi numerici, solo opinioni di esperti.