If you use the naked domain, the cookies which are not host-only and have domain set get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly.
This is also bad for security. If you have cookies on your main domain that matter and some vendor then convinces someone at your company to CNAME hosted-app.yourdomain.com to their service, any XSS holes in that vendor’s product could steal your core domain cookies.
I recently had to put a super short text with a domain into a newspaper ad. Targeting non-experts.
I decided against https:// and opted for www. to signal ‘that’s an internet address’ to the (human) readers. Necessary because of the non-common TLD .name.
you’ve committed the atrocity of using an ID instead of a readable slug. Why would you do this?
Because slugs are hard. You need to generate them, add a database index for them and check & disambiguate duplicate slugs. Not too bad, you should have separate internal and public IDs anyway, the public one might as well be a string.
But what do you do if the page title changes? What if the author made a typo when drafting the post, fixed it, but you already generated the slug? Just live with it? What if the title was offensive/defamatory/contained confidential information? OK, you need to be able to change slugs.
But changing slugs will break old links and cool URLs don’t change, so you need to store the “slug history” for each post.
My own Denizen CMS uses slugs for posts with titles. I haven’t dealt with any of these yet.
edit: To clarify, none of these are insurmountable challenges or even good excuses. Just answering the question “why would you do this”.
I keep dates in my URLs because I quite often have two posts with the same title. E.g. talking about the same movie twice. Still no good for posting the same title twice on the same day but that’s an edge case I just put up with…
I will look at ditching the trailing slash though, it does make sense.
This is also more robust in case the user comes back and edit the title to something else, the link will still work. Also, it removes the requirement that slugs be injective – there is no issue if two different posts have the same slugs.
I love it when CMSs enforce dates in a URL. You’d be surprised how rarely authors and web designers think to include publication dates anywhere in the HTML, and publication date is often an important modifier to the information in the post.
That said, if the publication date were consistently available in the HTML (either in the layout, or in the metadata), I wouldn’t clutch so tightly to dates in URLs.
It’s quite frustrating when I want to archive a page in Zotero and there’s no publication date on the page. Sometimes if I’m lucky there’s a post list with it in there, but on some sites there’s nothing :(
I will lightly disagree with the date take. For me, I like it when the date is included (does not have to be 2025/02/25/post, could be 2025-02-25/post or even just 2025/post), since it’s a fairly nice way to know if the content is up to date without even opening the link, which I think is a big plus of readable URLs this post misses. I love it when I can mostly tell what a URL points to without opening it!
I wonder what the author would think of my blog. Each post has year and month in the URL (but no date, that was so fine-grained I decided it was pointless). You can remove any element from the hierarchy and get a real HTML page - time-filtered indexes of posts. I implemented this so you could filter by time without me having to run a (dynamic) search engine server-side.
Ah, a bike shed…
If you use the naked domain, the cookies which are not host-only and have domain set get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly.
This is also bad for security. If you have cookies on your main domain that matter and some vendor then convinces someone at your company to CNAME
hosted-app.yourdomain.comto their service, any XSS holes in that vendor’s product could steal your core domain cookies.I came here to say exactly this (and simonw’s point in the sibling comment to this). I will be clutching my
wwws until kingdom come. :)I recently had to put a super short text with a domain into a newspaper ad. Targeting non-experts.
I decided against https:// and opted for www. to signal ‘that’s an internet address’ to the (human) readers. Necessary because of the non-common TLD .name.
This is part of the reason I use non-www hosts. No naked domain, but no www either.
Because slugs are hard. You need to generate them, add a database index for them and check & disambiguate duplicate slugs. Not too bad, you should have separate internal and public IDs anyway, the public one might as well be a string.
But what do you do if the page title changes? What if the author made a typo when drafting the post, fixed it, but you already generated the slug? Just live with it? What if the title was offensive/defamatory/contained confidential information? OK, you need to be able to change slugs.
But changing slugs will break old links and cool URLs don’t change, so you need to store the “slug history” for each post.
My own Denizen CMS uses slugs for posts with titles. I haven’t dealt with any of these yet.
edit: To clarify, none of these are insurmountable challenges or even good excuses. Just answering the question “why would you do this”.
I keep dates in my URLs because I quite often have two posts with the same title. E.g. talking about the same movie twice. Still no good for posting the same title twice on the same day but that’s an edge case I just put up with…
I will look at ditching the trailing slash though, it does make sense.
My www ain’t going anywhere ;)
I like using just the year for that - it means you get to reset your namespace once a year, while avoiding your URLs getting too long.
If done properly, it can work as a built-in shortener.
https://example.com/p/58473/photos-of-cute-kittenshttps://example.com/p/58473This is also more robust in case the user comes back and edit the title to something else, the link will still work. Also, it removes the requirement that slugs be injective – there is no issue if two different posts have the same slugs.
But in this case the slug is meaningless. I avoid URLs like this because they look like they’ve been generated from the mind of a SEO guru.
No, when present, it tells the user a bit more about what the post is about. The OP mentioned it in #1 above.
I love it when CMSs enforce dates in a URL. You’d be surprised how rarely authors and web designers think to include publication dates anywhere in the HTML, and publication date is often an important modifier to the information in the post.
That said, if the publication date were consistently available in the HTML (either in the layout, or in the metadata), I wouldn’t clutch so tightly to dates in URLs.
It’s quite frustrating when I want to archive a page in Zotero and there’s no publication date on the page. Sometimes if I’m lucky there’s a post list with it in there, but on some sites there’s nothing :(
I will lightly disagree with the date take. For me, I like it when the date is included (does not have to be 2025/02/25/post, could be 2025-02-25/post or even just 2025/post), since it’s a fairly nice way to know if the content is up to date without even opening the link, which I think is a big plus of readable URLs this post misses. I love it when I can mostly tell what a URL points to without opening it!
I wonder what the author would think of my blog. Each post has year and month in the URL (but no date, that was so fine-grained I decided it was pointless). You can remove any element from the hierarchy and get a real HTML page - time-filtered indexes of posts. I implemented this so you could filter by time without me having to run a (dynamic) search engine server-side.
URL Design reminds me of (RIP) Aaron Swartzs “Building for Users: Designing URLs” in “The Programmable Web, an unfinished work” https://codeberg.org/mro/ProgrammableWebSwartz2013/src/branch/master/content/pages/2-building-for-users.md
Strong opinions - some with very weak arguments.
But it’s a good list of things to think about and make up your mind, if you never had to before.