-
Notifications
You must be signed in to change notification settings - Fork 52
[Enhancement] SEO optimization 3/3 - Don't use fragments for client-side navigation, but proper URLs #343
Comments
The first two I understand (I think), but this one not really. So what does it affect in case of Lychee? For what it's worth, we do use the According to that Google page, the crawler only considers the |
The point is that a search engine only considers two pages to be distinct and indexes them individually, if the path component of their URLs differ. The fragment is not taken into a account. (See Syntax Image on Wikipedia for path and fragment.) Fragments are intended to be used to navigate to different anchors (e.g. different scroll positions) on the same page. Lychee is violating that. Currently we are using the fragment part for navigation between different "pages". I guess we are using fragments, because it appeared to be easier as one can manipulate the But this means from the perspective of a web crawler that everything is on one page. If the web crawler revisits and re-indexes the page later and uses a different fragment part for that and hence sees a complete different thing, the previous index result will be overwritten. |
Thanks for pointing that out. I have already added some comments to the source code that we misusing |
The problematic |
I understand the reason for the search engine behavior when it comes to fragments, but what about queries ( |
Good question. I haven't looked into every detail thoroughly. I don't feel like doing so right now. Hence, in the following O only express my assumptions. From a theoretical perspective, the query part should matter. I mean, the query part is sent to the server (in contrast to the fragment) and the server may base its response on the query part. IMHO, it would be a bug if a web crawler would only consider the path. However, I would not bet on it. Given the fact that some web proxies and web caches failed to get that piece right some years ago, I would not try to push my luck too far. |
Currently, our web frontend is not very SEO friendly. It is entirely written in JS, which is fine for modern web crawlers, but it violates some best practices.
Enhancement: Currently the frontend uses fragments (i.e. the
#
-part of the URL) to implement client-side navigation. While client-side navigation is generally fine, it must not use fragments. Fragments are not only a problem for Twitter (although this is Twitter's fault), but search engine won't detect the different "pages" as being different and do not index fragments. Instead, the frontend should use proper URLs and the JS history API.See: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics#use-history-api
The text was updated successfully, but these errors were encountered: