-
Notifications
You must be signed in to change notification settings - Fork 567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion - Avoid 404's using meta tag #67
Comments
Tried it and it seems to work the same way. But has a lot less code and possibly the mentioned Google benefit. So seems like a better solution. Edit: I moved to s3 hosting with cloudfront, and what seemed to work in the end was this It still does redirects with |
Also worth referencing https://developers.google.com/search/docs/crawling-indexing/301-redirects#metarefresh
I'm trying this approach on https://njt1982.github.io/minecraft-item-browser/copper_block as Google didn't like it when I simply served the page using 404.html (basically copied index.html to 404.html during gh-pages deploy). Hoping this redirect approach makes it happier... Although I'm concerned that it will see all sub-pages as a 301 to the root of the repo. I'd really like each sub page to actually be its own URL. Might need to combine this approach with https://github.com/rafgraph/spa-github-pages... 🤔 EDIT: Although it looks like Google might respect History API, after all... https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics#use-history-api |
Smashing Magazine wanted to solve the same problem as this repository and I think their solution is fairly elegant as well. It involves a small 404 page.
Because there's the "refresh" header, this gets translated into a 301 response within the browser (ignoring the 404 status code from the server). To use this, the SPA needs a bit of JavaScript at the very beginning to load the route from session storage and use
replaceState
to update the URL.According to my quick searching, Google doesn't penalize 301 redirects nor the refresh header redirects, so this might be a viable alternative without putting the path after a hash.
The text was updated successfully, but these errors were encountered: