Skip to main content
Contributor ⭐️⭐️⭐️
November 30, 2022
Discovery

Get public URL before publishing

Related products:CC Moderation
  • November 30, 2022
  • 25 replies
  • 263 views

It would be fantastic to have a production ready URL before publishing content live. The current preview, includes preview and a few other things that means you can’t reference the URL in other content until pushing the content live. This post provides a workaround, but that is prone to manual error, typos, and a bunch of other issues. Please provide a better way to do this. 

25 replies

judahs
Helper ⭐️
June 9, 2026

Great callout, agreed, we need to make this consistent between surfaces (backend and frontend)

On the topic of IDs I’d also like to propose removing the numerical ID from the URL altogether--or at least providing that as a configuration option. The URLs would be much more predictable if you could expect the final output to just be the hyphenated topic name, without any system generated ID appended.

atwhite
Helper ⭐️⭐️⭐️
June 9, 2026

@judahs The IDs might become more predictable, but in my experience, the numerical ID plays a big role in ensuring that if a URL changes, old links to the content don’t break. This has been huge for us as we’ve reorganized the Community several times as content needs, lines of business, customer base, etc., all evolve over time. We know we can rename a Knowledge Base and trust that we don’t have to do a site-wide link analysis. 

 

But that said, all the more reason why the backend and frontend IDs should be consistent, so +1 from me on that as well. 😅

Larry
Helper ⭐️⭐️
June 9, 2026

Great callout, agreed, we need to make this consistent between surfaces (backend and frontend)

On the topic of IDs I’d also like to propose removing the numerical ID from the URL altogether--or at least providing that as a configuration option. The URLs would be much more predictable if you could expect the final output to just be the hyphenated topic name, without any system generated ID appended.

@judahs The IDs might become more predictable, but in my experience, the numerical ID plays a big role in ensuring that if a URL changes, old links to the content don’t break. This has been huge for us as we’ve reorganized the Community several times as content needs, lines of business, customer base, etc., all evolve over time. We know we can rename a Knowledge Base and trust that we don’t have to do a site-wide link analysis. 

 

But that said, all the more reason why the backend and frontend IDs should be consistent, so +1 from me on that as well. 😅

 

I will ask our engineering team about this but I have a hunch that ​@atwhite is right, it may be difficult to accomplish but it all depends on our technical architecture. Still, worth asking and exploring the pros and cons of that approach. It’s more readable / predictable from a human perspective but the research I’ve done already indicates that it is not a huge impact to SEO having numerical ID’s.

Larry Imgrund || Senior Product Manager & Community Nerd
judahs
Helper ⭐️
June 29, 2026

@judahs The IDs might become more predictable, but in my experience, the numerical ID plays a big role in ensuring that if a URL changes, old links to the content don’t break.

 

I will ask our engineering team about this but I have a hunch that ​@atwhite is right, it may be difficult to accomplish but it all depends on our technical architecture. Still, worth asking and exploring the pros and cons of that approach. It’s more readable / predictable from a human perspective but the research I’ve done already indicates that it is not a huge impact to SEO having numerical ID’s.

This a very good point, I am actually curious to learn more about the role of that ID and what role it plays with permalinks. I know that topics have two IDs, a public and a private ID. The public ID is what gets appended to the topic slug in the URL, and the private ID functions like a permalink in some way. I don’t know much about it, they work something like this: 

URL with public ID:

https://community-name.com/category/topic-name-[public-id]

URL with private ID: 

https://community-name.com/articles/[private-ID]

Unfortunately, I don’t think there is any way to find a topic’s private ID in Gainsight CC. We have Gainsight CC integrated with Gainsight CS instance, so I can report on community objects in CS and find a topic’s private ID there.

I’ve actually started using the private ID URL format above when someone needs an advance URL to use in a newsletter or a popup build since it’s a permalink. That way all I have to do is just push the topic up to my hidden “drafts” category in the knowledge base and then get its private ID. I don’t have to manually build a URL myself with the category I know it’s eventually going to move into. It’s still a manual workaround, but less opportunity for me to make a typo I guess 🤠

@Larry if the numerical ID in the slug can’t be removed easily, another improvement might be to just surface the article’s private ID in control somewhere so that type of a permalink URL could be used even if an article can’t be published/visible right away. 

Larry
Helper ⭐️⭐️
June 30, 2026

@judahs I hear you and it is an approach I’ll ask my team about. We are going to be working on requirements for a broader content publishing workflow soon and I’ve already been planning to fold this idea into that. Once I have an approach decided upon and a timeline to announce, I’ll post it here!

Larry Imgrund || Senior Product Manager & Community Nerd