Can't believe it: Sitefinity not SEO friendly after all?
Hello Sitefinity users,
Finally, after selecting Sitefinity in late 2010 (3.x era), I am now 2 weeks into building my first Sitefinity website. That's great as I was really looking forward to it. Unfortunately, a major issue came up: I can hardly believe that Sitefinity does not allow me to set a custom page default URL.
Yes, I can choose the last part of the URL. But if it's 5 levels deep into the sitemap/site hierarchy, the parent levels are forced in the URL as folders. I can set additional URL's which can be short, but they redirect to the long default one. That's great for moved pages, but it's no solution here. Furthermore, widgets are not aware of additional URL's. They will include default URL's in the HTML they generate.
So if my page is located in /category/subcategory/subsubcategory/subsubsubcategory/product, all I can change is "product"! The rest of the URL cannot be changed. If this is an important page (e.g. a product page, where the money is made), the URL is way too long. It's not user friendly as it's hard to remember and people are less likely to link to it. It's just not as SEO friendly as it can and should be. I want it to be "/product", or perhaps "/category/product".
For me it's a no-brainer that URL and page location should not be related. They can be, but it shouldn't be forced. Large websites need a nice navigational structure, but URL's need to be short in many cases.
Anyway, it seems that this was possible in Sitefinity 3.x by using the "Set as default" link:
In 5.x, it's not possible anymore, as confirmed by Telerik. A request has been logged into the PITS. Please vote for it!
I'm now waiting on more information from Telerik (at least an implementation date). In the mean time I wonder what do you think of this? How are you dealing with URL's in 5.x? Does anyone know of a workaround? I'm actually reconsidering Sitefinity as my CMS now as this is such a critical issue.
Sorry for the unfriendly links, the post editor doesn't let me create links. Thanks for your help!
Not only that...but enabling the documented SEO rules breaks a bunch of things...
...and there's nobody over there running the above rules in order to find and weed out the bugs. I've had to report them myself as I see them. Taxonomy filter widget just outright causes a YSOD with them enabled for example.
If we're promoting SEO, then make sure it works...especially if you've documented steps for people to setup IIS for SEO. You can't say "Do this", but then not have it work.
Thanks for your reply Steve. Well, I didn't even go that far. I think rewriting is sort of a final resort if a CMS is just not capable of producing normal URL's. Of course there are exceptions such as the upper/lower case and trailing slashes. But it shouldn't be necessary to use rewriting to make up for CMS limitations. Even if it works it won't result in a 100% SEO friendly website as widgets are not aware of the rewrite rules. They just keep on rendering whatever (long) URL is inside the Sitefinity sitemap.
Agreed, instructions should be tested and work. If not, a link to IIS documentation would be better.
Agree with you both. Just added my vote!
I have to work with sitefinity for a client and compared to wordpress it is terrible, not only in regard to SEO, but particularly there.
Try to add rich snippets and schema.org and you will run into troubles...
What bugs me is the official\unofficial word is that they just aren't going to bother to activly test or make it work.
It SHOULD come working out of the box to handle lowercase urls, trailing slashes or at the very least fixing the duplicate home URLs.
If you are promoting SEO, then make it work...
I always thought it was weird that the category browser control generated non-standard Uppercase Urls...that's one of those sloppy "polish" items. So it remains to be seen if they'll address this for 5.3 or not. I've done all I can emailing around, but its a crapshoot.
Thanks for your insights guys. I'm waiting for feedback through the support ticket regarding this issue. I'll post updates here if there's anything worth sharing.
@Raphael: what's the problem with rich snippets? I thought it was fairly easy to adjust the HTML rendered by Sitefinity.
@Steve: I agree. There's especially no excuse for the duplicate home URLs. That's such a basic SEO requirement. Working with redirects or canonicals shouldn't be necessary with any decent CMS. These are bandages for crappy systems. Great that they exist, but not a good sign if you have to use them for issues like these.
Please vote for the PITS: http://www.telerik.com/support/pits.aspx#/public/sitefinity/13346
I just came across a fun one :) ...what if I told you every page on your site was accessible via two URLs.
It's even worse Steve:
is the same page as
In other words: you can add anything to the URL. If Sitefinity recognizes the first part, it will happily return status code 200 and the page content. And there's no canonical tag on the page, so it's a classic SEO issue.
Every website build with Sitefinity has this issue. I just tried mine. Quite a major thing that deserves a PITS listing of its own.
Anyway, regarding this topic and the custom (short) URL's: I just got a reply from Telerik. They will not schedule this for implementation and recommend to set up 302 redirects.... (which would only make it worse). A high ranking in the PITS is the only way they may change their mind.
So please vote for the PITS: http://www.telerik.com/support/pits.aspx#/public/sitefinity/13346
I'm not sure what to do now. Have to think about it.
Already voted...tried to tweet about it #Sitefinity? :)
...actually also that PITS issue isn't about any SEO issue...doesn't even really address the "bug" so I doubt it'll be even related
Ok, after some additional research I've found two possible work arounds:
1) Put all pages that need to have a short URL in the root of the website. Disable "Show in navigation" to prevent them all showing up in the main menu, and link to these pages manually or through custom widgets. This allows the pages to be deep into the site (relative to the homepage) but still have a short URL. A breadcrumb path on such a page will reflect the short URL though, not the deep path.
2) Put all pages that need to have a short URL in their regular location in the sitemap of the website. Go into the page properties, enable "allow multiple URLs for this page" and configure a short URL there, e.g. ~/product. Do not enable "All additional URLs redirect to the default one". The second step is to prevent that the long default URL will ever be published on any page. The "mod_seo" module of the product "Ape" by Helicon can replace URLs in generated HTML just before it is send to the requesting browser. So you can instruct it to replace "/category/subcategory/subsubcategory/subsubsubcategory/product" with "/product".
[Edit November 21]: This only seems to work with output caching disabled: Administration - Settings - Advanced - System - Output Cache Settings - Enable Output Cache: false
So even though widgets output the long URL, the outside world will only see the short one as it's being replaced outside of Sitefinity. It seems to work in a simple test environment. No breadcrumb issues either. What still worries me is spending the time on testing and administrating this for lots of URLs, and possibly performance issues by adding another process to the webserver.
I have to test with this further so see if this works in more complicated environments than my test site.
It would be great if Telerik could share their ideas about option 2. Does this sound as something that could work? Do you see any problems with it?
Thnak you for sharing your workaround options with the community.
We would not recommend option 2 mainly due to the performance implications this might have on the project. Let me elaborate on this a bit further.
In order to provide the flexibility that comes with building dynamic pages with drag and drop widgets, and serving content dynamically, Sitefinity needs to build the requested page each time. Enabling output caching ensures this operation happens for the first request only, later the page is served from cache, thus delivering both faster performance to the user, and preventing excessive load on the server. Disabling output cache on a live site is not recommended as it would directly affect the site's performance and stability under heavy load.
In the same line of reasoning, but with a lower implication, having additional post-processing for the HTML will cause certain delays in delivering the content from the server to the browser, which, again, would have some effect on frontend performance optimization.
the Telerik team
You're right, it wouldn't be great from a performance point of view. Fortunately, the same Helicon product can cache modified pages as well (I did not test that yet). So I would turn off Sitefinity caching and use Helicon caching instead. Could that work? It seems like that would be another way to prevent Sitefinity to create pages on each request.
Of course this should all be a temporary solution. I need a work around to have short URL's. As soon as this is fixed in Sitefinity, I'll use Sitefinity caching again and turn off post processing. 11 votes already on the PITS, so I hope it will be implemented eventually.
I wanted to quickly jump in and say that we share your experience with the URLs and we have that same challenge with our website. We've managed to work around this for now but we don't consider this to be the solution. I've added the fix of the URL structure to my wish list for Sitefinity 6 which is expected in the spring.
Thanks for supporting this issue Martin. Please vote for the PITS as well if you didn't already (http://www.telerik.com/support/pits.aspx#/public/sitefinity/13346). What work around did you choose?
By "our site" i mean Sitefinity.com and i cast my vote with the product management group as well as on PITS as you suggested :) Here is one example of the issue, followed by our solution:
Obviously we don't want to have home/product/web-content-management since "web content management" is a key term for us and "/product" diminishes its SEO value. The way we solved this is we set the pages(web content management, mobile web, ecomerce, etc.) to not be children of "product". They are set as separate pages and we just told the navigation widget which pages to display and selected these separate pages. Like i said i don't think this is the permanent solution since this can get real messy as the site grows. We have a few ideas in mind and we'll discuss a good permanent solition for this.
Sorry, your name sounded familiar but I didn't realize straight away that you're a Telerik employee (and one with a bit of decision-making power I might add).
Good to hear that you fully understand the issue here. The work around used for Sitefinity.com sounds reasonable but indeed it gets messy for larger websites. I may choose that work around as well if the other one I discussed turns out to be too complex (still testing...).
I'm looking forward to your permanent solutions and the timeline.
While we're discussing the possible options for implementing the desired functionality, here's one more approach you might try for your content items in particular. When opening a content item in details mode (i.e. a News article, Blog post etc.) you can tell the widget to display these on a separate details page, which can be located in the root of the sitemap.
For example you can have you list of news on /home/mygrouppage/news, but specify the news widget to open the details item on a separate page - /news where you just need to have a News widget placed as well. Sitefinity will then automatically open the detail items on the specified page for you, and the links provided on the /home/mygrouppage/news page will point to /news.
All the best,
the Telerik team
I just tested that with forum threads on a page in the root and it works fine. Thanks for suggesting this. The breadcrumb will obviously show the short path (Root > Thread page), but other than that this is an option for content items.