it-swarm.dev

pushState e SEO

Molte persone hanno detto, usa pushState piuttosto che hashbang.

Quello che non capisco è, come vorresti essere amichevole nei motori di ricerca senza usare hashbang?

Presumibilmente il tuo contenuto pushState è generato dal codice JavaScript lato client.

Lo scenario è quindi:

Sono su example.com. Il mio utente fa clic su un link: href="example.com/blog"

pushState acquisisce il clic, aggiorna l'URL, acquisisce un file JSON da qualche parte e crea l'elenco dei post del blog nell'area del contenuto.

Con hashbang, google sa di andare sull'URL escaped_fragment per ottenere il loro contenuto statico.

Con pushState, Google non vede nulla in quanto non può utilizzare il codice JavaScript per caricare il JSON e successivamente creare il modello.

L'unico modo per farlo è vedere il template sul lato server, ma questo nega completamente i vantaggi di spingere il livello dell'applicazione sul client.

Quindi sto ottenendo questo, pushState non è SEO friendly per le applicazioni client-side?

76
Harry

Che dire dell'uso del meta tag suggerito da Google per coloro che non vogliono hash-bang nei loro URL: <meta name="fragment" content="!">

Vedi qui per maggiori informazioni: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Sfortunatamente non penso che NickC abbia chiarito il problema che pensavo avesse l'OP. Il problema è semplicemente che non sappiamo a chi stiamo servendo del contenuto se non usiamo l'hash-bang. Pushstate non risolve questo per noi. Non vogliamo che i motori di ricerca indichino agli utenti finali di navigare verso un URL che emette un JSON non formattato. Al contrario, creiamo URL (che attivano altre chiamate a più URL) che recuperano i dati tramite AJAX e li presentano all'utente nel modo che preferiamo. Se l'utente non è un essere umano, allora in alternativa possiamo fornire uno snapshot HTML, in modo che i motori di ricerca possano indirizzare correttamente gli utenti umani all'URL che si aspetterebbero di trovare i dati richiesti (e in modo presentabile). Ma la sfida finale è come determinare il tipo di utente? Sì, possiamo usare .htaccess o qualcosa per riscrivere l'URL per i robot dei motori di ricerca che rileviamo, ma non sono sicuro di come sia completo e futuro. Potrebbe anche essere possibile che Google potrebbe penalizzare le persone per aver fatto questo genere di cose, ma non ho fatto ricerche approfondite. Quindi la combinazione di combo (pushstate + google's meta tag) sembra essere una soluzione probabile.

16
prograhammer

pushState è male se hai bisogno di motori di ricerca per leggere il tuo contenuto?

No, il discorso su pushState è orientato a compiere lo stesso processo generale verso gli hashbang, ma con URL più belli. Pensa a cosa succede realmente quando usi hashbangs ...

Tu dici:

Con hashbang, Google sa di andare sull'URL escaped_fragment per ottenere il loro contenuto statico.

Quindi, in altre parole,

  1. Google vede un link a example.com/#!/blog
  2. Google richiede example.com/?_escaped_fragment_=/blog
  3. Si restituisce un'istantanea del contenuto che l'utente dovrebbe vedere

Come puoi vedere, si basa già sul server. Se non stai servendo un'istantanea del contenuto dal server, il tuo sito non viene indicizzato correttamente.

In che modo Google vedrà qualcosa con pushState?

Con pushState, google non vede nulla in quanto non può utilizzare il javascript per caricare il json e successivamente creare il modello.

In realtà, Google vedrà tutto ciò che può richiedere a site.com/blog. Un URL punta ancora a una risorsa sul server, e i clienti obbediscono ancora a questo contratto. Naturalmente, per i client moderni, Javascript ha aperto nuove possibilità di recupero e interazione con i contenuti senza un refresh di page, ma i contratti sono gli stessi.

Quindi l'eleganza desiderata di pushState è che serve lo stesso contenuto per tutti gli utenti, vecchi e nuovi, abilitati per JS e non, ma i nuovi utenti ottengono un'esperienza migliorata .

Come fai a Google per vedere i tuoi contenuti?

  1. L'approccio di Facebook - serve lo stesso contenuto all'URL site.com/blog che la tua app client si trasformerebbe in quando si inserisce /blog nello stato. (Facebook non usa pushState ancora che io sappia, ma lo fanno con hashbangs)

  2. L'approccio di Twitter: reindirizza tutti gli URL in arrivo all'equivalente di hashbang. In altre parole, un link a "/ blog" inserisce /blog nello stato. Ma se richiesto direttamente, il browser finisce con #!/blog. (Per Googlebot, questo sarebbe quindi indirizzato a _escaped_fragment_ come vuoi.Per altri client, pushState potrebbe tornare all'apposito URL).

Quindi perdi la capacità _escaped_fragment_ con pushState?

In un paio di commenti diversi, hai detto

il frammento sfuggito è completamente diverso. È possibile pubblicare contenuti non elaborati, contenuto memorizzato nella cache e non essere messi sotto il carico delle normali pagine.

La soluzione ideale è che Google faccia siti JavaScript o realizzi un modo per sapere che esiste un URL frammento di escape anche per i siti pushstate (robots.txt?).

I vantaggi che hai citato non sono isolati da _escaped_fragment_. Che faccia la riscrittura per te e usi un parametro GET appositamente chiamato è davvero un dettaglio di implementazione. Non c'è nulla di veramente speciale che non si possa fare con gli URL standard - in altre parole, riscrivi /blog in /?content=/blog da solo usando mod_rewrite o l'equivalente del tuo server.

Cosa succede se non si fornisce alcun contenuto sul lato server?

Se non riesci a riscrivere gli URL e a servire un qualche tipo di contenuto su /blog (o qualunque stato tu abbia inserito nel browser), allora il tuo server non rispetterà più il contratto HTTP.

Questo è importante perché una pagina di ricarica (per qualsiasi motivo) estrae il contenuto da questo URL. (Vedi https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source e reload recupereranno entrambi il contenuto nel nuovo URI se ne è stato inserito uno.")

Non è che disegnare interfacce utente una volta sul lato client e caricare il contenuto tramite API JS è un brutto obiettivo, è solo che non è realmente rappresentato con HTTP e URL e fondamentalmente non è retrocompatibile.

Al momento, questa è la cosa esatta a cui è destinato hashbang - per rappresentare stati di pagina distinti che sono navigati sul client e non sul server. Ad esempio, un ricaricamento caricherà la risorsa same che può quindi leggere, analizzare ed elaborare il valore hash.

Accade semplicemente che abbiano anche usato (in particolare da Facebook e Twitter) per cambiare la cronologia in una posizione lato server senza un aggiornamento della pagina. È in quei casi d'uso che le persone consigliano di abbandonare hashbang per pushState.

Se esegui il rendering di tutto il contenuto lato client, dovresti pensare a pushState come parte di un'API di cronologia più comoda e non a un modo per utilizzare hashbangs.

97
Nicole

Tutti i discorsi interessanti su pushState e #!, e ancora non riesco a vedere come pushState sostituisca lo scopo di #! Come chiede il poster originale.

La nostra soluzione per rendere il nostro sito/applicazione Ajax al 99% basato su JavaScript utilizza SEO #!, ovviamente. Poiché il rendering del client viene eseguito tramite HTML, JavaScript e PHP, utilizziamo la seguente logica in un caricatore controllato dal nostro landing page. I file HTML sono totalmente separati da JavaScript e PHP perché vogliamo lo stesso HTML in entrambi (per la maggior parte). JavaScript e PHP fanno la stessa cosa, ma il codice PHP è meno complicato dal momento che JavaScript è un'esperienza utente molto più ricca.

JavaScript utilizza jQuery per iniettare in HTML il contenuto che desidera. PHP usa PHPQuery per iniettare nell'HTML il contenuto che vuole - usando 'quasi' la stessa logica, ma molto più semplice dato che la versione PHP verrà utilizzata solo per visualizzare una versione SEOable con link SEOable e non essere interagito con come la versione JavaScript.

Tutti sono i tre componenti che compongono una pagina, page.htm, page.js e page.php esistono per tutto ciò che utilizza il frammento di escape per sapere se caricare la versione PHP al posto della versione JavaScript. La versione PHP non ha bisogno di esistere per contenuti non SEOable (come le pagine che possono essere viste solo dopo l'accesso dell'utente). Tutto è semplice.

Sono ancora perplesso sul modo in cui alcuni sviluppatori front-end scappano sviluppando ottimi siti (con la ricchezza di Google Docs) senza utilizzare tecnologie server-side in combinazione con quelle di browser ... Se JavaScript non è nemmeno abilitato, la nostra soluzione 99% JavaScript ovviamente non farà nulla senza il PHP sul posto.

È possibile avere un URL piacevole per atterrare su una pagina PHP servita e reindirizzare a una versione JavaScript se JavaScript è abilitato, ma non è bello dal punto di vista dell'utente poiché gli utenti sono il pubblico più importante.

In una nota a margine. Se stai creando un semplice sito web che può funzionare senza JavaScript, allora posso vedere che pushState è utile se vuoi migliorare progressivamente la tua esperienza utente da un semplice contenuto reso staticamente in qualcosa di meglio, ma se vuoi dare il tuo utente la migliore esperienza in viaggio ... diciamo che il tuo ultimo gioco scritto in JavaScript o qualcosa di simile a Google Docs, quindi è utile per questa soluzione è un po 'limitante in quanto con grazia si può arrivare così lontano prima che l'esperienza utente sia dolorosa rispetto alla visione del sito.

0
Julian