Ask HN: URL format for blog posts - which format is best? | Hacker News Reader

Ask HN: URL format for blog posts - which format is best?

6 pointsdesign-of-homes8 comments

Example 1:

myblog.com/my-readable-but-long-blog-post-title-in the-url

myblog.com/posts/my-readable-but-long-blog-post-title-in the-url

Example 2:

myblog.com/2022/08/my-readable-but-long-blog-post-title-in the-url

Example 3:

myblog.com/62642060

---

Pro and cons:

Examples 1 and 2: Readable but long URLs. They may also help SEO (search engine optimisation).

Example 2: The date in the URL provide helpful context.

Example 3: A short URL easily shared (but URL is not descriptive).

Which of these URL formats do you prefer? Or do you think they don't really matter?

Thank you :-)

View on HN

I think example one is the best. First, having date in URL sounds great but it is really just metadata. It is also relative to where you live. You might want to add multilingual features at some point. Or if you need to pull down a post and republish it at a later date now you might be stuck with multiple aliases. Having a descriptive title in the URL usually provides enough insight for someone just seeing the link to know what is is about. Sometimes bookmark managers mess up and lose titles. If you see the URL it is helpful to know what the content represents. Tools like Hugo will do this for you automatically as well.

Example 1 with the `posts/` prefix for canonical url.

Even with that canonical url, you can still provide your own url shortening service a la example 3. Given the choice, I'd slightly prefer using a first party shortener that maps a single shortened link per piece of content versus third party one creating a shortened link per share.

year/month prefix is useful to readers if the content becomes stale quickly.

It doesn't really matter to me that much because it's all useless and too long to remember that I will bookmark everything I care about and give them a proper name handwritten title by myself, but if I had to choose, it would instead look something like the urls in software documentation:

> https://en.cppreference.com/w/cpp/container/vector

See? You don't even need to open it to know what's going to be there.

Sadly, it's kind of hard to map for arbitrary blog topics so I can't give you a realistic example for how it would work there, but I guess if you made a post about new foreign recipe, it could probably be

> /<country of interest>/<topic of interest>/<object of interest>

> /japan/food/salmon

Your imagination is your only limit and I recommend you stop to think about what is the purpose of spending that much time on it, and you may find what you need.

My thinking would be this:

* If you have a subdomain for your blog(example: blog.mydomain.com) then you don't need /posts

* if you don't have subdomain, you can use /posts, to distinguish between regular pages of your site and blog articles. Because you might have mydomain.com/about and mydomain.com/contact pages

* Don't put metadata such as publish dates as it can be modified or changed in the future. Also it's relative.

* As for example 3, you would probably need it in case when you have lots of articles and there might be a slug collision. I wouldn't worry about that unless you are media organization

Things like /article or /blog or /posts signal to Google the type of content.

Having a date in the URL also signals how fresh the content is.

Google also state that descriptive URLs get higher click throughs via search than non descriptive.

Personally I'd go with example 1, option 2.

What I would ALSO do however, is add JSON-LD structured markup data to each post page, as I know Google uses it to classify and date your content.

Not sure if this is the best, but here's what I do.

/article/postNumber/Article-Title

e.g.:

https://theandrewbailey.com/article/266/Cinco-de-Mayo-Burger...

I've always been succinct in my titles, so getting overly long URLs isn't much of an issue, except on HN comments.

If talking about proposed ones I like first approach. But I have seen even better approach when readable-title-in-url is short and custom. For example, article with header "My Readable But Long Blog Post" may be just myblog.com/readable

I tend to avoid time related information on my website. I try my best to write evergreen content, showing the date almost always brings negative consequences such as people bouncing off your website before reading.

Reply on news.ycombinator.com