W aplikacji z jedną stroną, jaki jest właściwy sposób postępowania z błędnymi adresami URL (błędy 404)?

Question

Obecnie piszę aplikację internetową za pomocą angularjs, ale myślę, że to pytanie dotyczy dowolnej struktury javascript po stronie klienta, która wykonuje routing po stronie klienta (as angular does).

W przypadku aplikacji obsługującej jedną stronę, jaki jest właściwy sposób postępowania z nieprawidłowymi adresami URL?

Patrząc na kilka głównych witryn, widzę, że Gmail przekieruje do skrzynki odbiorczej, jeśli wpiszesz dowolny losowy adres URL poniżej https://mail.google.com/mail/. Dzieje się to po stronie serwera (z kodem http 300) lub po stronie klienta, w zależności od tego, czy błędna ścieżka jest przed czy po znaku #. Z drugiej strony, twitter pokazuje prawdziwy HTTP 404 dla każdego nieprawidłowego adresu URL. Trzecią opcją byłoby wyświetlenie "miękkiej" 404 strony błędu po stronie klienta.

Rozwiązania te wydają się odpowiednie w różnych sytuacjach. Twitter chce, aby linki do twitterów użytkowników i tweetów były prawdziwymi linkami, więc ludzie mogą je udostępniać, publikować w artykułach, itp., Więc ważne jest, aby nieprawidłowe linki były rozpoznawane jako takie (jeśli mam zepsuty link do tweeta w moja strona internetowa powie mi o tym proste przeszukiwanie). Z drugiej strony w Gmailu nie oczekuje się udostępniania linków w skrzynce odbiorczej i nie jestem nawet pewien, czy linki są naprawdę trwałe/trwałe: wydaje się, że aktualizacja adresu URL służy głównie nawigacji w historii przeglądarki aplikacja jednostronicowa. Trzecie podejście polegające na podawaniu delikatnych błędów może być odpowiednie w sytuacjach podobnych do Gmaila, ale tam, gdzie nie ma rozsądnej "domyślnej" strony.

Po tym długim wstępie, oto kilka konkretnych pytań:

• Czy kiedykolwiek akceptowalne dać „miękką” stronę błędu zamiast błędu 404, lub powinny aplikacja pojedynczej strony zawsze przekierować do prawdziwe 404, jeśli adres URL jest nieprawidłowy?
• Kod Gmaila może być całkowicie bezbłędny, ale jeśli wystąpił błąd prowadzący do nieprawidłowych linków, które w końcu przekierowują z powrotem do skrzynki odbiorczej, może to być jeszcze bardziej zagmatwane dla użytkowników niż strona błędu. W przypadku większości aplikacji internetowych, które nie są tak dobrze przetestowane jak Gmail, lepiej byłoby wyświetlić stronę błędu?
• Aby zaimplementować prawdziwe 404 dla aplikacji jednostronicowych, wydaje się konieczne skopiowanie logiki routingu po stronie serwera. Czy jest jakiś sposób obejścia tego?
• Podczas przekierowania do 404, myślę, że użytkownik powinien być w stanie zobaczyć adres URL, który spowodował błąd, prawdopodobnie na pasku adresu URL. Dzięki api historii html5 myślę, że można to osiągnąć przez proste wywołanie przeładowania bieżącej strony (z niewłaściwym adresem URL) w połączeniu z routingiem po stronie serwera wspomnianym powyżej. W przeglądarkach, które nie obsługują tego lub podczas korzystania z notacji hashbang, nie wydaje się to możliwe. Jaki jest najlepszy sposób na obsługę wszystkich przeglądarek?

Answer 1

tl; dr: Drop hashbang wsparcie i zdecydować się PJAX podobnego zachowania, jeśli dbasz o SEO.

Czy tworzysz aplikację lub stronę internetową? Jeśli strona internetowa musisz zwrócić 404, aby nie mylić google. To musi być prawdziwy 404 nie tylko pokazać komunikat o stronie nie znaleziono (np. 200 z komunikatem "nie znaleziono strony" jest bardzo złe). Jakie przeglądarki również chcesz obsługiwać?

Moja opinia jest taka, że ​​należy unikać renderowania po stronie serwera hashbang (np. Nieprzyjemnego haseł SEO firmy Google #!). Użyj prawdziwego pststate lub ponownie wyrenderuj całą stronę, jeśli adres URL ulegnie zmianie w przypadku przeglądarek, które nie obsługują parametru pushstate (a nie zmiany hash).

Teraz powodem tego jest to, że liczy #! nigdy nie powinien zwracać 404 bo to nie ma sensu, a jego niemożliwe do naśladowania po stronie serwera, ponieważ serwer nie dostaje co jest po #! z zewnątrz działa Javascript.

Tak więc, jeśli naprawdę zależy Ci na SEO, zrobiłbym coś takiego jak PJAX i użyłbym tylko prawdziwego pushstate do routingu, a następnie nie powiodło się do starego web 1.0. W związku z tym linki, które polecam Ci udostępnić, które naprawdę mogą być 404 nie powinny mieć #! (tradycyjne # jest w porządku, o ile zawartość strony nie zmienia się drastycznie).

Wreszcie 404 nie stanowi większego problemu, ale raczej 30X tj. Odpowiedzi przekierowania. To dlatego, że przeglądarka automatycznie obsługuje przekierowania, więc twoje wywołania JavaScript AJAX nigdy nie zobaczą 30X (otrzymają zamiast tego odpowiedź przekierowania ... tj. 200). Aby obsłużyć odpowiedzi 30X, będziesz musiał wysłać nagłówek z powrotem dla każdego żądania, aby wskazać przekierowany adres URL (tj. Do którego został przekierowany), aby nie zepsuć historii Pushstate.

Oczywiście, jeśli potrzebujesz wsparcia dla hashbang takich jak Twitter (and they are the ones that even killed hashbang), możesz wykorzystać Google Sitemaps i rel=nofollow, aby złagodzić złe SEO.