Browser Name should match current article title
under review
Alice Ingham
The browser name seems to matches the first title of the article when created. This is annoying if the article title needs changing. We use chrome. See image for an example:
Log In
K
Katharina Leonhardt
How do I change the browser tab name of an index category?
Anna McDonald
I agree that the browser name should match the current article title. It's taxing to have to update metadata for articles created from templates or copies. Besides, I have a backlog of 1000+ articles that were pulled in via migration that have an old prefix on them. It would help to have it all match, even if this is presented as an optional global setting.
Caroline Tabach
This issue also happens when you create a new article from a template - often the new article has the name of the template itself and does not get updated when you apply the actual name to the article itself
Anna McDonald
Caroline Tabach: Thanks for pointing this out! I did not catch that, and I need to go back and fix all the articles I created from a template.
Thiru
under review
Thiru
Alice Ingham Whenever the article title is updated based on the content then respective SEO title also requires to be updated, so that browser tab name reflects the appropriate name. Sure, we will keep this in our radar to update this. Thanks for your feedback.
Alice Ingham
Thiru: Thank you!
Shannon Greywalker
Thiru: I'd like to suggest a _better_ solution. This root cause (the SEO string setting) is not at all obvious to the typical team contributor.
Why not implement the same UX pattern you use when somebody re-words the article STUB? If you do that, the confirmation dialog includes a warning checkbox asking whether you want to also create a corresponding redirect.
If you apply this SAME pattern to the article title, then when somebody re-words the article TITLE, the confirmation dialog could include a warning checkbox asking whether you want to also overwrite any existing SEO string.
Andrew Belter
Thiru: Does this also apply to private (or mixed) KBs? If so... then that's another reason this should be bumped up on the priority list, because we have no reason to look at any SEO settings in a private KB that's behind logins and not being indexed by search engines
Alice Ingham
Shannon Greywalker: I think this is a great idea