Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

Going lowercase with nice urls, by default or not?

Important question regarding nice url.

In the old legacy times the url were generated with lowercase+underscore filter, then at some point the default switched to anycase+dash. Both ways are actually not good for SEO. We continuously need to switch this to lowercase+dash on all major projects. SEO experts don’t like anycase and don’t like underscore. We will implement the lowercas+dash in our project skeleton but the question is should this be by default in eZ?

Please share your experiences

UPDATE: seems like there is a feature request for this: https://jira.ez.no/browse/EZP-28811

1 Like

I’m big +1 for this. Shortly, all the seo teams i’ve met ask for this kind of configuration by default. I’ve never met any asking for the one that ez provides by default.


Small +1, i would prefer a yml params in order to activate, just as the same kind we got for SiteAccess url matching type. I’m saying that in order to not “lock” every project where sometime they would wanted anycase.
Having it by default would be cool, but having the choice would be nicer :slight_smile:

yeah, i’m not against allowing the choice.

Choice is ok. I am also for making it configurable. But the lowercase+dash should be the default as its recognized as the industry best practice.


I myself also like lowercase+dash as a default I have to admit.
But this should be configurable for sure.

However, I hear the ones saying AnyCase is not good for SEO but did you collect some strong data / proof about that? I was looking for some a long time back and could not find super solid facts backing this which is more to me almost an “aesthetic” preference.

We’ll look into this in any way.

Its not an aesthetic thing. I have no hard data, but just the fact that on every project where we have SEO people we get this request. The main point is that with AnyCase you have much bigger chance to screw the analytics data. Google is case sensitive in some situations. With lowercase we normalize the urls better.


Google basically states that the mixed case should make little to no difference to them, but they prefer consistency in the URLs, and in these terms the mixed case is the worst possible choice there is.

I agree with you regarding your statement that the mixed case has no SEO impact when it comes to eZ routes. It doesn’t really matter which case you use, since eZ will 301 redirect you to the version of the URL with the capitalisation that is stored in the database.

However, the bigger problem is trying to explain this to the client or the SEO teams. Most of the SEO teams have little to no experience with the eZ, and usually are blindly following the same guidelines for eZ websites as they would for some Wordpress site.

Most of the clients insist on this because they are told this is the best practice and they want to follow it no matter what you say. Which kind of becomes a huge problem when they decide to do it after two or three years of site being in production, and we have to regenerate URLs for 100+ thousands of locations on a live database. Not to mention potential loss of the history alias entries during the process, and the number of redirects that will occur after the conversion to lowercase - and that will eventually make a significant impact in search indexes.

If you would state that the SEO should always have been done before even going live, I would absolutely agree with you. Unfortunately, we don’t live in the perfect world, and most clients tend to ignore it or won’t cover it with the project budget before going live, and they will realise that it actually makes a difference only after they see the drop in page views or search index ratings.

So to summarise my point, as a web developer, I would rather try to avoid the problems above if possible :slight_smile: Nobody ever wanted to switch the lowercase to mixed case, it’s always the other way around.


One of the important things here is having a choice, so proper semantic configuration for specifying available transformation groups and the currently used group is a must. Every other solution runs the risk of breaking in the long run if eZ decides to change the API, which would then probably result in respones like: “we never said it a public API”. That itself is okay, but to remedy that, proper semantic configuration is much needed.

I would absolutely prefer lower case by default. I’ve always felt that and certain translitteration (ö -> oe, ä -> ae, å -> oe) to be different from virtually any other product. Maybe it’s the “right way”, but I’d just join them if you can’t beat them :wink:

Having a configuration option would be optimal.

Hey guys,

I was just coming back to this discussion.
As you can see, there’s been work done to implement this, and some of you contributed (https://github.com/ezsystems/ezpublish-kernel/pull/2306).

So far configuration is done however, I’m not sure we decided to have this by default.
Some raised that going lower case by default could be see as a BC break.
To me, as long as we offer for the one upgrading the ability to upgrade to a configuration that matches their previous url, it isn’t a BC break.

  • upgrade would go to anycase+dash
  • new instals based on defauld would go to lowercase+dash

any last bit of inputs there before we ship this in 2.2?

That sounds like a good plan!

How will you make sure this happens? Will it be part of install instructions?

Documentation and install instruction is my thought indeed.
Any thought here @bdunogier ?

Hi everyone!
Here is the story for the upgrade: https://jira.ez.no/browse/EZP-29167

Feel free to comment.

1 Like