Как правильно обрабатывать неправильные URL-адреса (ошибки 404) в одностраничном приложении?

Если вы заботитесь о поисковой оптимизации, то эту проблему можно решить с помощью angular.io (по крайней мере, с Google) - это использование метатега noindex «для обозначения статуса soft-404, который не позволит сканерам сканировать содержимое страницы». Судя по всему, это можно добавить в документ через JavaScript.

В качестве альтернативы, используя JavaScript, вы можете перенаправить на страницу, которая ответит фактическим кодом состояния HTTP 404. Google прекрасно понимает перенаправления JavaScript. Ваша исходная страница /does-not-exist при перенаправлении на /404-error?from=does-not-exist будет связана с кодом состояния 404, возвращаемым сервером. Структура URL-адреса не имеет значения, здесь важны только код состояния и перенаправление.

Другие варианты: SSR (Nuxt.js, Next.js, Angular Universal и т. Д.) Или предварительный рендеринг (prerender.io, puppeteer и т. Д.), Который Google называет динамический рендеринг, где вы отвечаете на запросы поисковых ботов с предварительно обработанной версией, в то время как пользователи-люди получают ваше обычное приложение, отрисованное на стороне клиента.

tl; dr: Откажитесь от поддержки hashbang и выберите поведение, подобное PJAX, если вы заботитесь о SEO.

Вы делаете приложение или веб-сайт? Если сайту нужно вернуть 404, чтобы не запутать гугл. Это должно быть реальное 404, а не просто показывать сообщение о том, что страница не найдена (т.е. 200 с сообщением «страница не найдена» - это очень плохо). И какие браузеры вы хотите поддерживать?

Я считаю, что следует избегать всего рендеринга на стороне сервера хэшбэга (т. Е. Неприятного взлома Google SEO #!). Либо используйте реальное pushstate, либо повторно визуализируйте всю страницу, если URL-адрес изменяется для браузеров, которые не поддерживают pushstate (не изменение хэша).

Причина, по которой это имеет значение, заключается в том, что #! никогда не должен возвращать 404, потому что это не имеет смысла и невозможно имитировать серверную часть, потому что сервер никогда не получает то, что после #! без запущенного Javascript.

Таким образом, если вы действительно заботитесь о SEO, я бы сделал что-то вроде PJAX и использовал бы только true pushstate для маршрутизации, а затем просто не смог бы перейти на старую веб-версию 1.0. Следовательно, ссылки, которыми я рекомендую вам поделиться, которые действительно могут быть 404, не должны иметь #! (традиционные # подойдут до тех пор, пока содержимое страницы не изменится кардинально).

Наконец, 404 в основном не проблема, а скорее 30X, т.е. ответы перенаправления. Это потому, что браузер автоматически обрабатывает перенаправления, поэтому ваши вызовы Javascript AJAX никогда не увидят 30X (вместо этого они получат ответ перенаправления ... т.е. 200). Чтобы обрабатывать 30X ответы, вам нужно будет отправлять заголовок обратно для каждого запроса, чтобы указать, какой URL был перенаправлен (то есть, на что вы были перенаправлены), чтобы вы не испортили историю Pushstate.

Конечно, если вам нужно поддерживать хэшбанг, например, Twitter (, и именно они убили hashbang), вы можете использовать Google Sitemaps и _ 15_, чтобы попытаться снизить влияние плохого SEO.