Best practice HTTPS per SEO e usabilità

Prendi in considerazione una pagina, http://example.comche può essere visualizzata sia pubblicamente che quando un utente esegue l'autenticazione. Supponiamo ora di abilitare HTTPS per ogni pagina quando un utente accede al tuo sito Web, ma solo quando sono connessi. La tua pagina http://example.comora diventa https://example.comper tutti gli utenti che hanno effettuato l'accesso. Se l'utente che ha effettuato l'accesso gradisce la tua pagina e decide di collegarla tramite un post di blog o un sito Web di social media, è probabile che utilizzerà la versione HTTPS dell'URL.

Dal punto di vista SEO, qual è la tua strategia per evitare duplicati di contenuti tra i due URL?

Cosa dovrebbe accadere se un utente arriva all'URL HTTPS ma non ha effettuato l'accesso o non ha un account? Dovrebbe esserci un reindirizzamento alla versione HTTP? In tal caso, come lo gestiresti?

Il mio istinto è che per tutte le pagine che possono essere visualizzate sia pubblicamente sia durante l'accesso, la pagina dovrebbe prima rilevare se l'utente ha effettuato l'accesso. Se ha effettuato l'accesso, rimane HTTPS o utilizza un reindirizzamento 302 dalla versione HTTP a HTTPS. Se l'utente non ha effettuato l'accesso e arriva alla versione HTTPS dell'URL, utilizza un reindirizzamento 301 alla versione HTTP. Tuttavia, accolgo con favore una soluzione più elegante o efficace.

Modifica : supponevo che se un utente ha effettuato l'accesso, ogni URL dovrebbe essere HTTPS (o almeno, dovrebbe essere un'opzione), ma dato che ho fatto un po 'più di ricerca, forse l'ipotesi era sbagliata. Il modo in cui vedo le persone che lo implementano è che abilitano HTTPS solo per le pagine che inviano e ricevono dati sensibili: login, checkout del carrello, gestione del profilo utente, ecc. Sto cercando di capire quale modello è il migliore.

Apparentemente, Google Mail offre agli utenti la possibilità di utilizzare HTTPS su ogni pagina tramite un'impostazione nel profilo dell'utente. Questa è certamente un'opzione, ma avrei comunque bisogno di affrontare il comportamento delle pagine pubblicamente disponibili per tutti gli stati di autenticazione.

Poiché sto creando un sistema di gestione dei contenuti che verrà utilizzato da altre persone, devo assicurarmi di farlo bene. Quali impostazioni dovrebbero essere disponibili per il proprietario del sito? A questo punto, sto pensando a un controllo granulare su ogni pagina (indipendentemente dal fatto che sia protetto con SSL) e quindi anche per l'intero sito. Tuttavia, dare quel livello di controllo potrebbe essere un errore se le persone non capiscono tutti i problemi e potrebbero finire per causare problemi di sicurezza. Questo, forse, è il primo problema. Quali sono i livelli appropriati di controllo e quali sono le impostazioni predefinite intelligenti? Il secondo è come le pagine dovrebbero comportarsi per l'utente. Dal punto di vista SEO, penso che o il processo che ho descritto sopra o l'utilizzo direl="canonical" (come suggerito da jmb) funzionerebbe, ma è essenziale anche inchiodare il comportamento della pagina in modo che sia sicura e senza interruzioni.

Potresti voler esaminare <link rel="canonical" />. Vedi http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html . Giù nei commenti qualcuno di Google afferma che può essere utilizzato per problemi http / https.

Avvertenza: non sono sicuro se e in che misura <link rel="canonical" />sia supportato da motori di ricerca diversi da Google, Yahoo e Bing. Se altri motori sono importanti per il tuo sito, dovresti controllare le loro FAQ.

Dal punto di vista dell'utente: il reindirizzamento di un utente che ha effettuato l'accesso da http a https non è sicuro (se capisco correttamente che si desidera creare un processo continuo). Nel momento in cui arriva al sito (prima del reindirizzamento) trasferisce il suo cookie di sessione tramite http, rendendolo vulnerabile al dirottamento della sessione. Tale utente deve accedere nuovamente da una pagina https.

Nel caso in cui un utente arrivi tramite https e non abbia effettuato l'accesso: a seconda delle circostanze (dimensioni del sito, volume di traffico previsto, numero previsto di volte in cui ciò accadrà) potresti essere semplicemente in grado di tenerlo su https. Vedi anche HTTPS per l'intero sito e /programming/174348/will-web-browsers-cache-content-over-https per discussioni sulla gestione di un sito su https (in parte nel tuo caso).

Aggiornare:

Quali sono i livelli appropriati di controllo e quali sono le impostazioni predefinite intelligenti?

Livelli di controllo appropriati:

• Sicuro (https attivato, inclusa la pagina di accesso e tutto da lì in poi)

e

• Insicuro (no https).

Non c'è via di mezzo se si vuole "farlo bene". Vedi anche http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ e /programming/274274/is-it-secure-to-submit -da-a-http-form-to-https

Predefinito: dipende da chi sono i tuoi clienti.

Non esiste una strategia SEO per le pagine SSL. Parte della definizione di cache è questa:

If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.

vedi: tutorial sulla cache

Quindi, al fine di prevenire la sovrapposizione con pagine non SSL in cui ciò potrebbe danneggiare il ranking, è avere le tue pagine sensibili SSL su URL completamente diversi.

Ironia della sorte, ho visto i motori di ricerca effettivamente archiviare e mantenere i collegamenti con l'URL HTTPS in essi. Ciò è in contrasto con ciò che normalmente dovrebbe accadere, ma lo fa nei casi in cui la pagina è un'area di accesso, è la home page o in caso contrario il pragma della cache è stato riscritto per consentire la memorizzazione nella cache. Direi di evitarlo, se possibile, poiché la tua pagina scenderà nel PageRank di solito.

Il reindirizzamento 302 non trasferisce il ranking di ricerca, quindi potresti perdere il ranking di ricerca se aggiungi 302 al tuo sito.

301 può cambiare le definizioni dei segnalibri, non vorrei costantemente 301 i miei utenti in giro.

Inoltre, assicurati che la versione http includa un modulo di accesso in modo che l'utente possa tornare rapidamente alla versione https.

Ora la grande domanda è: se i dati sono visualizzabili su http, perché hai una versione https? quali dati nascondi con la crittografia https che non è già disponibile?

Puoi creare un'area membro https o pubblicare moduli per l'URL https dalla pagina http o molte altre opzioni che non includono avere l'intero sito su http e https.

A parte questo, la tua idea sembra fattibile, ma non ho informazioni interne su come funzionano Google e gli altri siti web e non puoi davvero essere sicuro di come questo influenzerà il tuo posizionamento (e il suo caso così marginale potrebbe cambia drasticamente ogni volta che Google aggiorna l'algoritmo).