Add post title to URL (investigate feasibility)

[cellio]

meta:292470

I've heard in the past that richer URLs are better for SEO. Even if that's no longer as true as it once was, having more information in a URL helps a reader decide whether to follow an inline link.

Is it practical to add post titles to the "default" URL? For example, https://meta.codidact.com/posts/292470 would become something like https://meta.codidact.com/posts/292470/add-post-type-and-title-to-the-URL. The short form would still work, but a link from a post list (category page, profile page, search results, etc) would use the longer form.

(Note that this issue is not exactly what that post asks for; I don't think it's practical to add post types, which can be defined through the UI.)

I'm marking this "analysis needed" because I don't know (a) how beneficial it is and (b) how hard it is.

[Oaphi]

No, please don't - having post titles in the URL was one of the most annoying things about SE. Human readable slugs are fine when the content is static. They are not for posts which can go through multiple revisions changing titles. While it's mitigatable via redirects, I'd avoid profileration of such links as it undermines the point of revising posts - and those links will proliferate as users generally don't think about cleaning up links.

[Oaphi]

That said, I actually think adding post types is a good idea, something along the lines of q/123/a/345 - those are trivially expandable and redirectable with an additional benefit of allowing users to cram more links in, for example, flag messages without resorting to stripping out the protocol or shortening them manually (not that applicable to us, but it's a big issue over on SE).

[cellio]

Oh, I didn't think about the disruption from changing titles. Good point. (I've been assuming that everything after the post ID is optional, so if you follow a link to /12345/old-title you'd get to /12345/new-title, but I don't know what's involved there either.)

For post types, how would you handle new types defined through the admin UI?

An alternative for helping users know where a link goes before clicking: maybe we could do a preview pop-up like you see here on GitHub if you hover over an issue link, or on Wikipedia for any link? Is there some standard way to do that?

[Oaphi]

I've been assuming that everything after the post ID is optional

Yeah, it is - although special handling would need to be set up and maintained for redirects to work (which is straightforward to do, though, just a couple of updates to our route definitions). It's the fact that there's going to be a lot proliferation of outdated titles that's bothering me so much about such links.

For post types, how would you handle new types defined through the admin UI?

Pretty easily - we have that information at our fingertips, and as for the short slug - we could just add a field that asks the admins to provide a "short slug" for the type. If we wanted to go the easy way, we could simply make the field required, but if we wanted to go the fancy way, we could keep the full slug if the short slug is not provided.

maybe we could do a preview pop-up like you see here on GitHub

That's a bit too fragile, and also requires the request to actually go through - which should never, ever be done for the user (tracking, phishing, spam - only a few things that could go wrong). That said, if we wanted to get really fancy, we could have a whitelist of domains we explicitly allow to preview (it'd also synergize well with what we discussed about having a domain whitelist for links in edit comments).

[cellio]

On that last point: I meant only for our links, not all links. Just like you don't get a preview for external links on Wikipedia, you wouldn't on our posts either. We don't want to open the door to tracking, phishing, etc.

[Oaphi]

I meant only for our links, not all links

Ah, that is certainly doable (although it'll be a bit involved to implement properly)