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, prende 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?

Che dire dell’uso del meta tag suggerito da Google per coloro che non vogliono hash-bang nei loro URL:

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 problema per noi. Non vogliamo che i motori di ricerca indichino agli utenti finali di navigare verso un URL che emette un JSON non formattato. Invece, creiamo URL (che triggersno 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 come alternativa possiamo fornire un’istantanea 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 ansible che Google possa penalizzare le persone per aver fatto questo genere di cose, ma non l’ho studiato a fondo. Quindi il combo (meta tag di google + google) sembra essere una soluzione probabile.

pushState è negativo se hai bisogno di motori di ricerca per leggere i tuoi contenuti?

No, i discorsi su pushState sono orientati a compiere lo stesso processo generale verso gli hashbang, ma con URL più belli. Pensa a cosa succede veramente 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 ad 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 su 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 aggiornamento della pagina , ma i contratti sono gli stessi.

Quindi l’eleganza voluta di pushState è che serve lo stesso contenuto per tutti gli utenti, vecchi e nuovi, con capacità 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 trasformsrebbe in quando fai push /blog sullo stato. (Facebook non usa ancora pushState che io conosca, ma lo fanno con hashbang)

  2. L’approccio di Twitter: reindirizza tutti gli URL in arrivo all’equivalente di hashbang. In altre parole, un link a “/ blog” spinge /blog sullo stato. Ma se richiesto direttamente, il browser finisce in #!/blog . (Per Googlebot, questo verrà quindi indirizzato a _escaped_fragment_ come desideri.Per altri client, potresti pushState all’URL grazioso).

Quindi perdi la capacità pushState con pushState ?

In un paio di commenti diversi, hai detto

il frammento sfuggito è completamente diverso. È ansible pubblicare contenuti non trattati, 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 a _escaped_fragment_ . Che faccia la riscrittura per te e usi un parametro GET nome speciale è 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 su /?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 qualche tipo di contenuto in /blog (o in qualsiasi altro stato inserito nel browser), 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 del nuovo URI se ne è stato inviato uno.”)

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

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

È solo che sono stati anche utilizzati (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 raccomandano di abbandonare hashbang per pushState.

Se pushState 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.

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

La nostra soluzione per rendere il nostro sito / applicazione Ajax 99% basato su JavaScript basato su JavaScript utilizza #! 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 di PHP verrà utilizzata solo per visualizzare una versione SEOable con collegamenti SEOable e non essere interagita con 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 di PHP al posto della versione di JavaScript. La versione PHP non ha bisogno di esistere per contenuti non SEOable (come pagine che possono essere viste solo dopo l’accesso dell’utente). Tutto è semplice.

Sono ancora perplesso sul modo in cui alcuni sviluppatori di 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, allora la nostra soluzione 99% JavaScript ovviamente non farà nulla senza il PHP in atto.

È ansible avere un URL piacevole per atterrare su una pagina PHP servita e redirect 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, 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ò andare così lontano prima che l’esperienza utente sia dolorosa rispetto alla visione del sito.