In un'applicazione a singola pagina, qual è il modo giusto per gestire URL errati (errori 404)?

Question

Attualmente sto scrivendo un'applicazione web usando angularjs, ma penso che questa domanda si applica a qualsiasi framework javascript lato client che esegue il routing sul lato client (as angular does).

In un'applicazione a pagina singola, qual è il modo giusto per gestire gli URL sbagliati?

Guardando alcuni siti importanti, vedo che gmail reindirizzerà la posta in arrivo se si digita un URL casuale sotto https://mail.google.com/mail/. Questo accade sul lato server (con un codice http 300) o lato client, a seconda che il percorso sbagliato sia prima o dopo il carattere #. D'altra parte, Twitter mostra un vero HTTP 404 per qualsiasi URL non valido. Una terza opzione sarebbe quella di mostrare un "soft" 404, una pagina di errore puramente lato client.

Queste soluzioni sembrano appropriate per diverse situazioni. Twitter vuole che i link per Twitter utenti e tweet siano collegamenti reali, quindi le persone possono condividerli, postarli in articoli di notizie, ecc., Quindi è importante che i link non validi siano riconosciuti come tali (se ho un link interrotto a un tweet in il mio sito web, una semplice ricerca per indicizzazione lo dirà). In Gmail, d'altra parte, non ci si aspetta che tu condivida i link nella tua casella di posta, e non sono nemmeno sicuro che i link siano permanenti/persistenti: sembra che l'aggiornamento dell'URL abbia principalmente lo scopo di navigare nella cronologia del browser all'interno del app a pagina singola. Il terzo approccio di dare errori soft potrebbe essere appropriato per situazioni simili a gmail, ma dove non esiste una pagina "predefinita" ragionevole.

Dopo questa lunga premessa, qui ci sono alcune domande specifiche:

• E 'mai accettabile per dare una pagina di errore "soft" al posto di un errore 404, o dovrebbe una singola pagina app reindirizzare sempre ad un vero 404 se un URL non è valido?
• Il codice di Gmail può essere perfettamente privo di errori, ma se ha un errore che porta a link non validi che finiscono per reindirizzare nuovamente alla posta in arrivo, ciò potrebbe essere ancora più confuso per gli utenti di una pagina di errore. Per la maggior parte delle app Web disponibili, che non sono testate come Gmail, sarebbe meglio mostrare una pagina di errore?
• Per implementare real 404 per applicazioni a pagina singola, sembra necessario duplicare la logica di routing sul lato server. C'è un modo per aggirare questo?
• Durante il reindirizzamento a un 404, penso che l'utente dovrebbe essere in grado di vedere l'URL che ha causato l'errore, probabilmente nella barra degli indirizzi. Con l'API della cronologia html5, penso che ciò possa essere ottenuto semplicemente attivando un ricaricamento della pagina corrente (con l'URL errato), combinato con il routing sul lato server sopra menzionato. Per i browser che non supportano questo o quando si utilizza la notazione hashbang, questo non sembra possibile. Qual è il modo migliore per supportare tutti i browser?

Answer 1

tl; dr: goccia hashbang sostegno e optare per PJAX come comportamento se si cura di SEO.

Stai creando un'app o un sito web? Se il sito web è necessario restituire 404 in modo da non confondere google. Deve essere un vero 404 non solo mostrare un messaggio di pagina non trovato (ad esempio, 200 con messaggio "pagina non trovata" è molto male). Anche quali browser ti preoccupi di supportare?

La mia opinione è che l'intero rendering del lato server hashbang dovrebbe essere evitato (vale a dire il brutto Google SEO #! hack). O utilizzare il vero pushstate o ri-renderizzare l'intera pagina se l'URL cambia per i browser che non supportano lo stato pushstate (non una modifica hash).

Ora il motivo per cui questo conta è che un #! non dovrebbe mai restituire un 404 perché non ha senso e la sua impossibilità di imitare lato server perché il server non viene mai che cosa è dopo la #! con fuori l'esecuzione di JavaScript.

Quindi, se davvero ti interessa il SEO, farei qualcosa come PJAX e usare solo vero pushstate per il routing e quindi fallire nel vecchio web 1.0. Di conseguenza, i link che ti consiglio di condividere che possono essere veramente uno 404 non dovrebbero avere #! (tradizionale # sta bene fino a quando il contenuto della pagina non cambia drasticamente).

Infine il 404 non è principalmente un problema, ma piuttosto 30X ie risposte di reindirizzamento. Questo perché il browser gestirà automaticamente i reindirizzamenti in modo che le tue chiamate AJAX JavaScript non vedano mai uno 30X (riceveranno invece la risposta di reindirizzamento ... cioè 200). Per gestire le risposte 30X, devi inviare un'intestazione per ogni richiesta per indicare che cosa è/era l'URL reindirizzato (ovvero a cosa sei stato reindirizzato) in modo da non rovinare la cronologia delle statistiche di pushstate.

Ovviamente se hai bisogno di supportare hashbang come Twitter (and they are the ones that even killed hashbang), puoi sfruttare Google Sitemaps e lo rel=nofollow per cercare di attenuare il cattivo SEO.