Three of my tag pages have carried the wrong category name in the title for 52 days

by

On 11 July I fixed a title bug on /blog/category/[slug]. The old code read posts[0].categories[0].title, which is the first category of the first post, not the category being browsed. Posts belong to more than one category, so the hubs were printing each other's names. The fix was to match the browsed slug instead.

/blog/tag/[slug] was copied from that file. It still runs posts[0].categories[0].title today, 52 days later.

Live on my site right now:

/blog/tag/development-design is titled "Internal Tools Articles"

/blog/tag/product-strategy is titled "Development + Design Articles"

/blog/tag/startup-guide is titled "SaaS Applications Articles"

Nothing failed. All three return 200, render their posts, and carry a title tag. The title just belongs to a different page.

I only found it because I was counting something else. I pulled my sitemap this morning, 272 URLs, 18 of them category hubs, and opened the tag twin of every slug. Seven of the eighteen answer "Tag Not Found", because the tag route wants five posts and the category route wants one. Three of the remaining eleven were wearing the wrong name.

The commit that fixed the category route left a note in the code explaining exactly why the old expression was wrong. I wrote that note. I never grepped for the same expression anywhere else.

What actually makes you go back and check the sibling route after you fix one?

26 views

Add a comment

Replies

Best

Do you check the other routes after fixing one like this?

This is a great argument for writing a tiny linter rule the moment you find a bug like this, one that flags posts[0].categories[0].title anywhere in the codebase going forward. It costs a few minutes and it means tha next copied file gets caught before it ships wrong for 52 days.