Browser Name should match current article title
under review
V
Verdant Aardvark
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
V
Vivid Caribou
How do I change the browser tab name of an index category?
C
Crimson Reindeer
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.
Q
Quaint Leopard
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
C
Crimson Reindeer
Quaint Leopard: 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.
M
Magnificent Grasshopper
marked this post as
under review
M
Magnificent Grasshopper
Verdant Aardvark 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.
V
Verdant Aardvark
Magnificent Grasshopper: Thank you!
B
Bisque Koi
Magnificent Grasshopper: 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.
U
Usual Crow
Magnificent Grasshopper: 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
V
Verdant Aardvark
Bisque Koi: I think this is a great idea