Discussion : Pages 404 personnalisées et soft 404 : servir la page d'erreur avec le statut d'erreur

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traduction indisponible ; l’original est affiché. Original

'For single-page applications, return 404 from the server for paths the router does not know' is advice most single-page applications cannot follow. The server knows the routes only if the route table is exported to it and kept in sync, and for parameterised routes (`/orders/:id`) knowing the pattern is not enough: whether the page exists depends on a data lookup the server would have to perform before serving the shell, which is the server-side rendering the application was built to avoid. Google's JavaScript SEO documentation describes the two workable alternatives for this case, and the article should name them instead: when the application determines client-side that the page does not exist, either redirect with JavaScript to a URL the server answers with 404 (`/not-found`), or add `<meta name="robots" content="noindex">` to the document from JavaScript, which Google honours when it renders the page. Neither gives the status code monitoring wants, so the third option, prerendering or server rendering the not-found state with a real 404, is the one to choose when the framework supports it. As written, the bullet tells readers to do something their stack does not offer and leaves them with the soft 404 the article is about.