In einer Einzelseiten-App, was ist der richtige Weg, um mit falschen URLs umzugehen (404 Fehler)?

Question

Ich schreibe gerade eine Webanwendung mit angularjs, aber ich denke, diese Frage gilt für jedes clientseitige JavaScript-Framework, das auf Client-Seite Routing durchführt (as angular does).

In einer einseitigen App, was ist der richtige Weg, um mit falschen URLs umzugehen?

Mit Blick auf einige wichtige Websites, sehe ich, dass Google Mail in den Posteingang umleiten wird, wenn Sie eine beliebige URL unter https://mail.google.com/mail/ eingeben. Dies geschieht serverseitig (mit einem HTTP-Code von 300) oder clientseitig, je nachdem, ob der falsche Pfad vor oder nach dem # -Zeichen liegt. Auf der anderen Seite zeigt Twitter ein echtes HTTP 404 für jede ungültige URL. Eine dritte Option wäre, eine "weiche" 404, eine rein clientseitige Fehlerseite, anzuzeigen.

Diese Lösungen scheinen für verschiedene Situationen geeignet. Twitter möchte, dass die Links zu Twitter-Nutzern und Tweets echte Links sind, so dass Leute sie teilen, in News-Artikeln veröffentlichen können, also ist es wichtig, dass ungültige Links als solche erkannt werden (wenn ich einen Link zu einem Tweet unterbrochen habe) Meine Website, eine einfache Crawl wird mir das sagen). In Google Mail hingegen wird nicht erwartet, dass Sie Links in Ihren Posteingang teilen. Ich bin mir nicht einmal sicher, ob die Links wirklich permanent/persistent sind: es scheint, dass die Aktualisierung der URL hauptsächlich der Browsernavigation dient Einzelseiten-App. Der dritte Ansatz, weiche Fehler zu geben, könnte für Situationen ähnlich wie Google Mail geeignet sein, aber wo es keine vernünftige "Standard" -Seite gibt.

Nach dieser langen Einführung, sind hier einige spezifische Fragen:

• Ist es überhaupt akzeptabel, eine „weiche“ Fehlerseite anstelle eines 404-Fehler zu geben, oder sollte eine Einzelseiten-App umleiten immer ein real 404 wenn eine URL ungültig ist?
• Der Code von Google Mail ist möglicherweise fehlerfrei, aber wenn ein Fehler zu ungültigen Links führt, die in den Posteingang zurückgeleitet werden, ist das für Benutzer möglicherweise noch verwirrender als eine Fehlerseite. Für die meisten Web-Apps, die nicht so gut getestet sind wie Google Mail, wäre es besser, eine Fehlerseite zu zeigen?
• Um echte 404 für einseitige Anwendungen zu implementieren, scheint es notwendig, die Routing-Logik auf der Serverseite zu duplizieren. Gibt es einen Weg dazu?
• Bei der Weiterleitung zu einem 404 sollte der Benutzer die URL sehen können, die den Fehler verursacht hat, möglicherweise in der URL-Leiste. Mit der html5-History-API glaube ich, dass dies erreicht werden kann, indem einfach ein erneutes Laden der aktuellen Seite (mit der falschen URL) ausgelöst wird, kombiniert mit dem oben erwähnten serverseitigen Routing. Für Browser, die dies nicht unterstützen oder wenn die Hashbang-Notation verwendet wird, scheint dies nicht möglich. Was ist der beste Weg, um alle Browser zu unterstützen?

Answer 1

tl; dr: Tropfen Hash-Bang-Unterstützung und für PJAX Verhalten entscheiden, wenn Sie über SEO kümmern.

Machen Sie eine App oder eine Website? Wenn Website Sie müssen 404 zurückgeben, damit Sie Google nicht verwechseln. Es muss eine echte 404 nicht nur eine Nachricht der Seite nicht gefunden werden (dh 200 mit der Nachricht "Seite nicht gefunden" ist sehr schlecht). Welche Browser möchten Sie unterstützen?

Meine Meinung ist, dass das ganze Hashbang-Server-Side-Rendering vermieden werden sollte (dh die böse Google SEO #! Hack). Verwenden Sie entweder den tatsächlichen Pushstate oder die gesamte Seite neu, wenn sich die URL für Browser ändert, die keinen Pushstatus unterstützen (keine Hash-Änderung).

Jetzt ist der Grund, warum dies wichtig ist, dass ein #! sollte nie eine 404 zurückkehren, weil es Server-Seite zu imitieren macht keinen Sinn und es ist unmöglich, weil der Server nie was kommt nach dem #! mit out Javascript ausgeführt wird.

Also, wenn Sie wirklich SEO interessiert, würde ich etwas wie PJAX tun und nur echte Pushstate für Routing und dann einfach zu alten Web 1.0 fehlschlagen. Folglich die Links, die ich empfehle Sie teilen, dass ein 404 sollte nicht #! (traditionelle # ist in Ordnung, solange der Inhalt der Seite nicht drastisch geändert werden).

Schließlich ist die 404 meistens kein Problem, sondern 30X dh Redirect-Antworten. Das ist, weil der Browser automatisch Umleitungen behandelt, so dass Ihre Javascript AJAX Anrufe nie eine 30X sehen werden (sie erhalten stattdessen die Weiterleitungsantwort ... dh 200). Um Antworten auf 30X beantworten zu können, müssen Sie für jede Anfrage einen Header zurücksenden, um anzugeben, was die umgeleitete URL ist (dh wohin Sie weitergeleitet wurden), damit Sie den Pushstate-Verlauf nicht durcheinander bringen.

Natürlich, wenn Sie Hashbang wie Twitter unterstützen müssen auch verwendet werden (and they are the ones that even killed hashbang), können Sie Google Sitemaps und die rel=nofollow versuchen, schlechte SEO zu mildern.