search

pdinklag / MinecraftStats

A Minecraft player statistics browser for the web - supports 1.13 and later!
https://discord.gg/brH5PGG8By
Other
227 stars 53 forks source link

SEO optimization: friendly slugs, metadata and sitemaps #181

Open weihao opened 2 years ago

weihao commented 2 years ago

current: https://example/#player:c73cc074-d167-3117-8758

wanted: https://example/players/notch

We should consider using the display name of a player for better SEO. We should also include a sitemap and better metadata.

pdinklag commented 2 years ago

current: https://example/#player:c73cc074-d167-3117-8758 wanted: https://example/players/notch

There are really three issues here, we might consider wanting to split them up. But for now some points could be discussed here.

Metadata for SEO

Never thought about anybody care for this as it's not meant as a front page at all, but sure, this could easily be generated.

UUID vs. Name

I agree that it's more straightforward to use names. There are a few points why I (still) use UUIDs.

  1. First, while player names can be changed, using a UUID will always lead to the same player no matter their name. This allows bookmarks to your own or your friend's stat page that will never become invalid, and I've also used this as a debugging tool (since Minecraft's stat filenames are the players' UUIDs). So I'd like UUIDs to still be supported as a means to permalinking.
  2. From a technical standpoint, the client would need a mapping between player name and UUID because there is no server-side request handling. A JSON containing a mapping can become several hundred kilobytes large and I opted to keep traffic as low as possible, so right now, mappings are only stored for as many players as need to be displayed (e.g., only players that have awards are stored in the summary). Of course, one can easily argue that on many websites, just the background image displayed in the navigation area is probably of megabyte proportions, so this can likely be changed back.
  3. One could also thinkg about saving the mapping and use names for player identification all throughout MinecraftStats. This would be a bigger task because currently, everything is handled via UUIDs internally. Minecraft stores data only for UUIDs and not player names, so if for whatever reason the Mojang API doesn't work (seen it down in the past, also Floodgate servers can't use it) and no entry is found in the usercache, the only possible fallback would be to use the UUID as the name. I also don't know if names are guaranteed to be unique and/or if they can contain symbols not allowed in filenames or URLs so they need special preprocessing.

Passing a mapping to clients may be much easier and I should stop worrying about the kilobytes, especially due to browser caching. This would make several other things much simpler again at the mere cost of a slight traffic peak when loading the page for the first time, so count me in.

Directory-style URLs

The reason I'm using the anchor-style URLs (#) is because they can be evaluated in onhashchange and (only) the necessary content needs to be swapped with no page reload (and script re-initialization) necessary. Also, the site works without having to configure anything in the webserver.

I'm honestly not sure if or how directory-style URLs can be achieved without any webserver setup? Surely without any special setup, when requesting https://example/players/notch, the webserver will attempt to access an index file in the players/notch directory – but it may be that I'm simply not aware of solutions here.

After all, it'd be nice to have this, but the setup must remain as simple as possible.