![](https://cdn.userecho.com/characters/75.png?1)
Feature request: URL/titles for SEO
Instead of URLs picking up an asset's title then generating new URLs when titles are changed, could we consider an SEO title field where an editor could manually define a phrase that would appear in a URL? And the URL wouldn't change as the asset's headline changes?
Example: Story about mass shooting in Baton Rouge
SEO/URL title: Baton Rouge mall shooting
Article asset title: 5 dead in Baton Rouge mall shooting
URL (that wouldn't change): theadvocate.com/baton_rouge/news/baton_rouge_mall_shooting/XYZABC123.html
Right now we shy away from opting for titles in URLs b/c of the mess it creates with multiple URLs per asset.
This would be used very often by us.
Answer
![](https://cdn.userecho.com/characters/75.png?1)
Bumping this idea. Another one we feel like would be a big advantage. We don't include titles in URLs right now b/c BLOX generates new URLs every time you change the headline. Even though BLOX smartly uses canonical URLs, we're told that's still not optimal for SEO. And it creates an analytics nightmare :(
![](https://cdn.userecho.com/characters/65.png?1)
Thirded. The way Blox URLs work now is a huge PITA, makes it tough to link, permalink, or deep link, and breaks one of the most basic UI conventions of the web. Of course, it looks like it would take a major re-architect of the CMS to do it right, so I'm not holding my breath.
![](/s/cache/86/78/8678fccc68c8a12d52a4416eb9ef3a5d.png)
Other parts of the URL would be indeed difficult, but the part in the middle (where the title is) is virtualized, so it can be changed. =)
![](/s/cache/5f/10/5f107910f618e75cbc6905b48c9fc635.png)
Love this idea. Tracking analytics of one story with multiple headlines isn't practical on the day-to-day.
![](/s/cache/86/78/8678fccc68c8a12d52a4416eb9ef3a5d.png)
A URL title field will be included in a future release (due out in a few months).
It is empty by default, indicating BC behavior.
Then you just type in some words, like "one two three four" and then at save time it cleans them up to "clean-two-three-four." That is then used as the asset title in the URL (if you have titles in URLs enabled).
This "URL Title" is then frozen, regardless of whether the headline changes.
All references to this URL (such as links from front pages, etc.) would use this new URL.
Again, the dev is done on this and it is about to go to QA.. so it will probably be available in Q2.
Let me know what you think!
![](/s/cache/86/78/8678fccc68c8a12d52a4416eb9ef3a5d.png)
As I was typing this, I could hear Kyle's voice in my head saying, "This is great, but can it be set with the title automatically?" So, I've added a request for that. I will let you know whether it is difficult or if it may be added.
![](https://cdn.userecho.com/characters/75.png?1)
Thanks, Christine. Definitely interested in it being automatic. A couple other thoughts?
-- Could the field actually exist beneath the title field like in Kevin Cox's Wordpress example?
-- Would this feature mean that BLOX URLs will no longer change when the headline is changed (assuming you have the URL option enabled in BLOX).
This is going to be a great addition, Christine, thank you!
![](/s/cache/86/78/8678fccc68c8a12d52a4416eb9ef3a5d.png)
Hi guys!
We had a release yesterday which added part of this feature, but it doesn't do everything that is discussed here in this first version.
But, for now, we see two use cases:
==> 1. Publisher has a bad or short title on their article, but they want to be able to expand it in the URL.
So maybe, for some cutesy reason the title of the story is "M13," so your URL would look like this:
https://flex-showcase.bloxcms.com/m/article_32d040a8-43f5-11e8-944f-57cba1de66fc.html
Note that we automatically remove numbers, because they are more likely to change, so you end up with a stupid-looking URL basically, with just "m" there!
In these cases, you may want to be able to change the title or change the URL so that you can create something that is more SEO-friendly, and also user friendly (if you share the "m" URL above, it doesn't have any good keywords or let you know anything about it).
Buy with this URL title feature, you can go in there and type something that can be used instead. So you end up with this:
Note that it allows the number to be in there, so that makes things more clear in some cases (like m13 where you need that for SEO, really).
Note that, in theory, it could go the other way as well. You might have a page that has a long page title, but you wanted it to be shorter or more precise (again, for SEO and for usability), you could do that also.
==> 2. Publisher would like their URLs to remain static so it doesn't mess up statistics or other external services such as Facebook comments.
In this situation, it's more that you want the URL to remain the same for statistics, rather than that you want to "fix" it from some unattractive state. The new feature is meant to address the situation above, but it is not likely to fix the statistics issue.
A few thoughts there:
Firstly, software like Chartbeat and Parsley can be updated to key off of the article UUID instead of the URL.
This will mean that they will all be tracked together regardless of section or title change.
Secondly, we are looking at doing some kind of permanent URL that would remain frozen, but we haven't agreed yet what that would look like.
Wordpress has a little Edit button that allows this (like Kevin's example). Basically, after the title is written, a few seconds later it populates the "permalink" slug area. If you edit it after it is published, it creates a 404 (that you can fix if you create a 301 redirect manually, it sounds like).
So, in our situation, we could possibly do something like that...
The problem is that BLOX is a little different because many users will actually write content in BLOX that may span many days. It is common that you see an asset in the system that has a start date of 2037 and the title is "Second story about the mayor TK" or whatever. So, in those cases, you'd theoretically end up with that in your URL, even if you change your title later.
It is possible we could tie the URL creation to a workflow status... i.e. it doesn't auto-fill the URL until it its a publish state, and then it freezes.
I have also seen some CMSes where they will have a "generate URL" button that, when pressed, will generate the URL and freeze it.
Interested to hear your thoughts...
![](https://cdn.userecho.com/characters/75.png?1)
Thanks, Christine. I think, kind of an asset's publication date/time, the creation of a URL should be directly tied to when an asset's 'do not publish' box has been unchecked for the first time.
While GA, Parsely, etc., can definitely track by UDID, it's still ideal for search/analytics to have one single URL per asset whenever possible. Like, that's the ultimate goal.
I think maybe creating some if-thens around the 'do not publish' box might be a possible universal solution?
![](https://cdn.userecho.com/characters/75.png?1)
Somewhat related: I think dates in URLs would be awesome too :)
theadvocate.com/baton_rouge/sports/lsu/2018/04/20/lsu-wins-2018-national-title/etcetcetc
![](/s/cache/0b/6f/0b6fc4576e5ae79dd099c4f96629ac0d.png)
What we would love to see is the removal of the "article_12345..." part of the URL. I know it's a unique identifier, but they still make the urls quite unattractive and messy.
I like Kyle's idea of the date in the URL. Would it be possible to combine both the date and the url title to be the unique identifier? Something just to get rid of 40+ ugly characters.
website.com/news/news-article-title/article_a6ab5bb6-3c39-11e8-9fba-bb9c20eb0c3a.html
becomes
website.com/news/2018/04/23/news-article-title/
![](https://cdn.userecho.com/characters/75.png?1)
Eeeee ... I think we definitely need a UDID-type string in the URLs. I can't imagine analytics without them.
![](/s/cache/0b/6f/0b6fc4576e5ae79dd099c4f96629ac0d.png)
Ah, true... I never throught of them for analytics. But I'm sure other newsrooms utilize it more than we do. I wonder if there's a happy medium then... maybe 20 characters. :P
BTW, how do you use the UID for analytics?
Customer support service by UserEcho
Hi guys!
We had a release yesterday which added part of this feature, but it doesn't do everything that is discussed here in this first version.
But, for now, we see two use cases:
==> 1. Publisher has a bad or short title on their article, but they want to be able to expand it in the URL.
So maybe, for some cutesy reason the title of the story is "M13," so your URL would look like this:
https://flex-showcase.bloxcms.com/m/article_32d040a8-43f5-11e8-944f-57cba1de66fc.html
Note that we automatically remove numbers, because they are more likely to change, so you end up with a stupid-looking URL basically, with just "m" there!
In these cases, you may want to be able to change the title or change the URL so that you can create something that is more SEO-friendly, and also user friendly (if you share the "m" URL above, it doesn't have any good keywords or let you know anything about it).
Buy with this URL title feature, you can go in there and type something that can be used instead. So you end up with this:
https://flex-showcase.bloxcms.com/former-gang-members-offer-advice-on-how-to-combat-ms-13/article_32d040a8-43f5-11e8-944f-57cba1de66fc.html
Note that it allows the number to be in there, so that makes things more clear in some cases (like m13 where you need that for SEO, really).
Note that, in theory, it could go the other way as well. You might have a page that has a long page title, but you wanted it to be shorter or more precise (again, for SEO and for usability), you could do that also.
==> 2. Publisher would like their URLs to remain static so it doesn't mess up statistics or other external services such as Facebook comments.
In this situation, it's more that you want the URL to remain the same for statistics, rather than that you want to "fix" it from some unattractive state. The new feature is meant to address the situation above, but it is not likely to fix the statistics issue.
A few thoughts there:
Firstly, software like Chartbeat and Parsley can be updated to key off of the article UUID instead of the URL.
This will mean that they will all be tracked together regardless of section or title change.
Secondly, we are looking at doing some kind of permanent URL that would remain frozen, but we haven't agreed yet what that would look like.
Wordpress has a little Edit button that allows this (like Kevin's example). Basically, after the title is written, a few seconds later it populates the "permalink" slug area. If you edit it after it is published, it creates a 404 (that you can fix if you create a 301 redirect manually, it sounds like).
So, in our situation, we could possibly do something like that...
The problem is that BLOX is a little different because many users will actually write content in BLOX that may span many days. It is common that you see an asset in the system that has a start date of 2037 and the title is "Second story about the mayor TK" or whatever. So, in those cases, you'd theoretically end up with that in your URL, even if you change your title later.
It is possible we could tie the URL creation to a workflow status... i.e. it doesn't auto-fill the URL until it its a publish state, and then it freezes.
I have also seen some CMSes where they will have a "generate URL" button that, when pressed, will generate the URL and freeze it.
Interested to hear your thoughts...