Ist pushStateschlecht, wenn Sie Suchmaschinen benötigen, um Ihre Inhalte zu lesen?
Nein, das Gespräch pushStateist darauf ausgerichtet, den gleichen allgemeinen Prozess für Hashbangs durchzuführen, jedoch mit besser aussehenden URLs. Überlegen Sie, was wirklich passiert, wenn Sie Hashbangs verwenden ...
Du sagst:
Bei Hashbangs weiß Google, dass es zur URL "Escape_Fragment" geht, um deren statischen Inhalt abzurufen.
Mit anderen Worten,
- Google sieht einen Link zu
example.com/#!/blog
- Google-Anfragen
example.com/?_escaped_fragment_=/blog
- Sie geben eine Momentaufnahme des Inhalts zurück, den der Benutzer sehen sollte
Wie Sie sehen können, hängt es bereits vom Server ab. Wenn Sie keinen Snapshot des Inhalts vom Server bereitstellen, wird Ihre Site nicht ordnungsgemäß indiziert.
Wie wird Google mit pushState etwas sehen?
Mit pushState sieht Google einfach nichts, da es das Javascript nicht zum Laden des JSON und zum anschließenden Erstellen der Vorlage verwenden kann.
Tatsächlich wird Google sehen, was es anfordern kann site.com/blog. Eine URL verweist weiterhin auf eine Ressource auf dem Server, und Clients halten sich weiterhin an diesen Vertrag. Natürlich für moderne Kunden hat Javascript neue Möglichkeiten für die Beschaffung und die Interaktion mit Inhalten ohne geöffnet Seite erneuern, aber die Verträge sind die gleichen.
Die beabsichtigte Eleganz von pushStateist, dass es allen Benutzern, alten und neuen, JS-fähigen und nicht JS-fähigen Inhalten den gleichen Inhalt bietet, aber die neuen Benutzer erhalten eine verbesserte Erfahrung .
Wie bringt man Google dazu, Ihre Inhalte zu sehen?
Der Facebook-Ansatz: Stellen Sie denselben Inhalt unter der URL bereit site.com/blog, in die sich Ihre Client-App verwandeln würde, wenn Sie /blogauf den Status klicken. (Facebook verwendet noch pushStatenicht, dass ich weiß, aber sie tun dies mit Hashbangs)
Der Twitter-Ansatz - Leiten Sie alle eingehenden URLs zum Hashbang-Äquivalent um. Mit anderen Worten, ein Link zu "/ blog" drängt /blogauf den Staat. Wenn es jedoch direkt angefordert wird, landet der Browser bei #!/blog. (Bei Googlebot wird dies dann _escaped_fragment_wie gewünscht weitergeleitet. Bei anderen Clients können Sie pushStatezur hübschen URL zurückkehren.)
Verlierst du also die _escaped_fragment_Fähigkeit mit pushState?
In ein paar verschiedenen Kommentaren haben Sie gesagt
entkommenes Fragment ist völlig anders. Sie können reine, nicht gedachte Inhalte und zwischengespeicherte Inhalte bereitstellen und dürfen nicht unter die Last gestellt werden, die normale Seiten haben.
Die ideale Lösung besteht darin, dass Google entweder JavaScript-Websites erstellt oder eine Methode implementiert, um zu wissen, dass selbst für Pushstate-Websites (robots.txt?) Eine URL mit Escapezeichen vorhanden ist.
Die von Ihnen genannten Vorteile sind nicht isoliert _escaped_fragment_. Dass es das Umschreiben für Sie erledigt und einen speziell benannten GETParameter verwendet, ist wirklich ein Implementierungsdetail. Es gibt nichts wirklich Besonderes, dass Sie nicht mit Standard - URLs tun können - mit anderen Worten umschreiben /blogzu /?content=/blogauf eigene Faust mit mod_rewrite oder Ihrem Server gleichwertig.
Was ist, wenn Sie überhaupt keine serverseitigen Inhalte bereitstellen?
Wenn Sie URLs nicht umschreiben und keine Inhalte bereitstellen können /blog(oder in welchem Status auch immer Sie sie in den Browser verschoben haben), hält sich Ihr Server wirklich nicht mehr an den HTTP-Vertrag.
Dies ist wichtig, da beim erneuten Laden einer Seite (aus welchem Grund auch immer) Inhalte unter dieser URL abgerufen werden. (Siehe https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "View-Source und Reload rufen beide den Inhalt am neuen URI ab, wenn einer gedrückt wurde.")
Es ist nicht so, dass das einmalige Zeichnen von Benutzeroberflächen auf der Clientseite und das Laden von Inhalten über JS-APIs ein schlechtes Ziel ist. Es ist nur so, dass es nicht wirklich mit HTTP und URLs berücksichtigt wird und im Grunde nicht abwärtskompatibel ist.
Im Moment ist dies genau das, wofür Hashbangs gedacht sind - um unterschiedliche Seitenzustände darzustellen, die auf dem Client und nicht auf dem Server navigiert werden. Beim erneuten Laden wird beispielsweise dieselbe Ressource geladen, die dann den Hash-Wert lesen, analysieren und verarbeiten kann.
Es ist einfach so, dass sie auch verwendet wurden (insbesondere von Facebook und Twitter), um den Verlauf ohne Seitenaktualisierung in einen serverseitigen Speicherort zu ändern. In diesen Anwendungsfällen empfehlen die Benutzer, Hashbangs für pushState aufzugeben.
Wenn Sie alle Inhalte clientseitig rendern, sollten Sie dies pushStateals Teil einer bequemeren Verlaufs-API betrachten und nicht als Ausweg aus der Verwendung von Hashbangs.