it-swarm.com.de

pushState und SEO

Viele Leute haben gesagt, verwenden Sie PushState anstelle von Hashbang.

Was ich nicht verstehe, ist, wie würden Sie ohne Hashbang suchmaschinenfreundlich sein?

Vermutlich wird Ihr pushState-Inhalt durch clientseitigen JavaScript-Code generiert.

Das Szenario ist also:

Ich bin bei example.com. Mein Benutzer klickt auf einen Link: href="example.com/blog"

pushState erfasst den Klick, aktualisiert die URL, greift von irgendwoher auf eine JSON-Datei zu und erstellt die Liste der Blogbeiträge im Inhaltsbereich.

Mit hashbangs kann google zu der URL escaped_fragment gehen, um deren statischen Inhalt abzurufen.

Mit pushState sieht Google einfach nichts, da es den JavaScript-Code nicht verwenden kann, um die JSON zu laden und anschließend die Vorlage zu erstellen.

Die einzige Möglichkeit, dies zu tun, ist das Rendern der Vorlage auf der Serverseite, was jedoch die Vorteile des Pushens der Anwendungsschicht auf den Client vollständig aufhebt.

Verstehe ich das also richtig, PushState ist überhaupt nicht SEO-freundlich für clientseitige Anwendungen?

76
Harry

Wie sieht es mit der Verwendung des Metatags aus, das Google für diejenigen vorschlägt, die keine Hash-Bangs in ihren URLs möchten: <meta name="fragment" content="!">

Weitere Informationen finden Sie hier: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Ich glaube leider nicht, dass NickC das Problem geklärt hat, von dem ich dachte, dass es das OP war. Das Problem ist einfach, dass wir nicht wissen, an wen wir Inhalte liefern, wenn wir den Hash-Bang nicht verwenden. Pushstate löst das nicht für uns. Wir möchten nicht, dass Suchmaschinen die Endbenutzer dazu auffordern, zu einer URL zu navigieren, die nicht formatiertes JSON ausspuckt. Stattdessen erstellen wir URLs (die andere Aufrufe zu mehr URLs auslösen), die Daten über AJAX abrufen und dem Benutzer in der von uns bevorzugten Weise präsentieren. Wenn der Benutzer kein Mensch ist, können wir alternativ einen HTML-Snapshot bereitstellen, so dass Suchmaschinen Benutzer ordnungsgemäß an die URL weiterleiten können, unter der sie die angeforderten Daten (und auf repräsentative Weise) finden würden. Die ultimative Herausforderung besteht jedoch darin, wie wir den Benutzertyp bestimmen. Ja, wir können möglicherweise .htaccess oder etwas verwenden, um die URL für Suchmaschinen-Bots, die wir erkennen, umzuschreiben, aber ich bin nicht sicher, wie umfassend und zukunftssicher dies ist. Es ist auch möglich, dass Google Menschen dafür bestraft, dass sie solche Dinge tun, aber ich habe es noch nicht vollständig recherchiert. Die Combo (Pushstate + Google Meta-Tag) scheint also eine Lösung zu sein.

16
prograhammer

Ist pushState schlecht, wenn Sie Suchmaschinen benötigen, um Ihre Inhalte zu lesen?

Nein, das Gespräch über pushState zielt darauf ab, denselben allgemeinen Vorgang für Hashbangs durchzuführen, jedoch mit besser aussehenden URLs. Überlegen Sie, was wirklich passiert, wenn Sie Hashbangs verwenden ...

Du sagst:

Mit Hashbangs weiß Google, dass es zur URL escaped_fragment geht, um seinen statischen Inhalt abzurufen.

Mit anderen Worten also

  1. Google sieht einen Link zu example.com/#!/blog.
  2. Google-Anfragen example.com/?_escaped_fragment_=/blog
  3. einen Schnappschuss des Inhalts anzeigen, den der Benutzer sehen soll

Wie Sie sehen, ist der Server bereits abhängig. Wenn Sie keine Momentaufnahme des Inhalts vom Server bereitstellen, wird Ihre Site nicht ordnungsgemäß indiziert.

Wie sieht Google dann etwas bei pushState?

Mit PushState sieht Google einfach nichts, da es das Javascript nicht verwenden kann, um den Json zu laden und anschließend die Vorlage zu erstellen.

Tatsächlich wird Google unter site.com/blog sehen, was es anfordern kann. Eine URL verweist immer noch auf eine Ressource auf dem Server, und Clients halten diesen Vertrag weiterhin ein. Für moderne Kunden hat Javascript natürlich neue Möglichkeiten für das Abrufen und Interagieren mit Inhalten ohne page -Auffrischung eröffnet, die Verträge sind jedoch gleich.

Die beabsichtigte Eleganz von pushState besteht also darin, dass alle alten und neuen Benutzer, JS-fähig und nicht, den gleichen Inhalt erhalten, sondern die neuen Benutzer erhalten eine erweiterte Erfahrung .

Wie bekommen Sie Google dazu, Ihre Inhalte zu sehen?

  1. Der Facebook-Ansatz: Stellen Sie denselben Inhalt unter der URL site.com/blog bereit, in die Ihre Client-App umgewandelt werden würde, wenn Sie /blog in den Status verschieben. (Facebook verwendet pushState noch nicht, wovon ich weiß, aber sie machen dies mit Hashbangs.)

  2. Der Twitter-Ansatz - leitet alle eingehenden URLs an das Hashbang-Äquivalent weiter. Mit anderen Worten, ein Link zu "/ blog" drückt /blog auf den Status. Wenn es direkt angefordert wird, endet der Browser mit #!/blog. (Für Googlebot würde dies dann nach _escaped_fragment_ geleitet, wie Sie möchten. Für andere Clients könnten Sie pushState zurück zu der hübschen URL).

Verlieren Sie also die _escaped_fragment_-Fähigkeit mit pushState?

In einigen verschiedenen Kommentaren sagten Sie

escape-Fragment ist völlig anders. Sie können reine Inhalte ohne Themedien und zwischengespeicherte Inhalte bereitstellen und nicht den normalen Seiten ausgesetzt sein.

Die ideale Lösung ist, dass Google entweder JavaScript-Websites erstellt oder eine Möglichkeit implementiert, zu wissen, dass es auch für Pushstate-Sites (robots.txt?) Eine URL mit Escape-Zeichen gibt.

Die von Ihnen erwähnten Vorteile sind nicht auf _escaped_fragment_ beschränkt. Dass es das Umschreiben für Sie übernimmt und einen speziell benannten GET-Parameter verwendet, ist wirklich ein Implementierungsdetail. Es ist nichts wirklich Besonderes, was Sie mit Standard-URLs nicht tun könnten - anders ausgedrückt, schreiben Sie /blog selbst in /?content=/blog um, indem Sie mod_rewrite oder die Entsprechung Ihres Servers verwenden.

Was ist, wenn Sie überhaupt keine serverseitigen Inhalte bereitstellen?

Wenn Sie URLs nicht umschreiben und irgendeine Art von Inhalt an /blog (oder welchen Status Sie in den Browser eingefügt haben) bereitstellen möchten, hält der Server den HTTP-Vertrag wirklich nicht mehr ein.

Dies ist wichtig, da durch das Neuladen einer Seite (aus welchem ​​Grund auch immer) Inhalt unter dieser URL abgerufen wird. (Siehe https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "" view-source und reload "holen den Inhalt an der neuen URI ab, wenn eine gepusht wurde.")

Es ist nicht so, dass das Zeichnen von Benutzeroberflächen auf der Clientseite und das Laden von Inhalten über JS-APIs ein schlechtes Ziel ist, es ist nur so, dass HTTP und URLs nicht wirklich berücksichtigt werden und es im Grunde nicht abwärtskompatibel ist.

Momentan ist genau das, wofür Hashbangs bestimmt sind, um verschiedene Seitenzustände darzustellen, die auf dem Client und nicht auf dem Server navigiert werden. Bei einem Neuladen wird beispielsweise die Ressource same geladen, die den Hashwert lesen, analysieren und verarbeiten kann.

Es ist nur zufällig, dass sie auch verwendet (insbesondere von Facebook und Twitter) verwendet wurden, um den Verlauf in einen serverseitigen Speicherort ohne Seitenaktualisierung zu ändern. In diesen Anwendungsfällen wird empfohlen, Hashbangs für pushState aufzugeben.

Wenn Sie den gesamten Inhalt clientseitig rendern, sollten Sie pushState als Teil einer bequemeren Verlaufs-API und nicht als Ausweg für die Verwendung von Hashbangs betrachten.

97
Nicole

Alle interessanten Gespräche über PushState und #!, und ich kann immer noch nicht erkennen, wie PushState den Zweck von #! Ersetzt, wie es das ursprüngliche Poster verlangt.

Unsere Lösung, um unsere 99% JavaScript-basierte Ajax-Site/Anwendung SEO-fähig zu machen, verwendet natürlich #!. Da das Client-Rendering über HTML, JavaScript und PHP erfolgt, verwenden wir die folgende Logik in einem Loader, der von unserer Seitenlandung gesteuert wird. Die HTML-Dateien sind vollständig von JavaScript und PHP getrennt, da in beiden (in den meisten Fällen) derselbe HTML-Code verwendet werden soll. Das JavaScript und PHP machen meistens dasselbe, aber der PHP Code ist weniger kompliziert, da das JavaScript eine viel umfangreichere Benutzererfahrung bietet.

Das JavaScript verwendet jQuery, um den gewünschten Inhalt in HTML einzufügen. PHP verwendet PHPQuery, um den gewünschten Inhalt in den HTML-Code einzufügen. Dabei wird "fast" dieselbe Logik verwendet, jedoch viel einfacher als die Version PHP. Diese Version wird nur zur Anzeige einer SEO-fähigen Version mit SEO-fähigen Links verwendet und nicht mit der JavaScript-Version interagiert werden.

Alle drei Komponenten, aus denen page, page.htm, page.js und page.php bestehen, bestehen für alle Elemente, die das escape-Fragment verwenden, um zu wissen, ob anstelle der JavaScript-Version die Version PHP geladen werden soll. Die Version von PHP muss nicht für nicht SEO-fähige Inhalte vorhanden sein (z. B. Seiten, die nur nach der Benutzeranmeldung sichtbar sind). Alles ist unkompliziert.

Ich bin immer noch verwirrt, wie einige Frontend-Entwickler großartige Websites (mit der Fülle von Google Docs) entwickeln können, ohne serverseitige Technologien in Verbindung mit Browser-Technologien zu verwenden ... Wenn JavaScript nicht aktiviert ist, dann ist unsere 99% JavaScript-Lösung wird natürlich nichts tun, wenn PHP nicht vorhanden ist.

Es ist möglich, dass eine Nice-URL auf einer PHP bereitgestellten Seite landet und zu einer JavaScript-Version umgeleitet wird, wenn JavaScript aktiviert ist. Dies ist jedoch aus Benutzersicht nicht Nice, da Benutzer die wichtigere Zielgruppe sind.

Als Randnotiz. Wenn Sie nur eine einfache Website erstellen, die ohne JavaScript funktionieren kann, kann PushState nützlich sein, wenn Sie Ihre Benutzererfahrung schrittweise von einem statisch gerenderten einfachen Inhalt zu etwas Besserem verbessern möchten Beste Erfahrung von Anfang an ... Nehmen wir an, Ihr neuestes Spiel ist in JavaScript oder in etwas wie Google Docs geschrieben. Dann ist die Verwendung für diese Lösung etwas einschränkend, da das grazile Zurückfallen nur so weit gehen kann, bis die Benutzererfahrung im Vergleich zur Vision schmerzhaft ist Der Seite.

0
Julian