OpenCart Community

I'm considering moving from our customized osC based solution to OpenCart, but the lack of features and in particular SEO URLs has really put me off.

I've seen some discussion on these forums about how it's not all that important to have proper SEO URLs and all that kind of rubbish, but from experience I can tell you that it makes a HUGE difference (trust me I know, our store ranks No. 1 on Google for VERY VERY competitive terms).

I really think the SEO URLs in OpenCart need to be addressed as a matter of priority.

To give you and understanding of what's needed on a URL by URL basis:
Static Pages (e.g. About Us, Contact Us, etc)
http://www.store.com/about-us OR http://www.store.com/about-us.html
http://www.store.com/contact-us OR http://www.store.com/contact-us.html

Product Pages (with or without .html on the end)
http://www.store.com/cpus/intel/intel-core-i7-cpu OR
http://www.store.com/cpus/intel/intel-core-i7-cpu-p1234 (where 1234 is the product Id) OR
http://www.store.com/intel-core-i7-cpu-p1234

It's actually better to have the Product Id in the URL and then if the name changes to do a 301 redirect to the new URL, as that will preserve the page rank.

Category Pages (with or without .html on the end)
http://www.store.com/categories/cpus/intel OR
http://www.store.com/cpus/intel-c123 OR
http://www.store.com/intel-cpus-c123

Same go as for products, best to have the ID in there and can have a cPath if needed.

Manufacturer Pages (with or without .html on the end)
http://www.store.com/brands/intel OR
http://www.store.com/intel-m123

Same go as for categories

Category Manufacturer Pages (with or without .html on the end)
http://www.store.com/kingston-memory-c123-m321

Paged data
http://www.store.com/kingston-memory-c123-m321-p2
http://www.store.com/kingston-memory-c123-m321-p3

Once again as previously mentioned it's important that the URL is checked when being

Also, it's important to limit the number of queries especially in the lists when generating these URLs, particularly when generating listing pages, so the appropriate data needed for seo needs to be retrieved in the single query with the products and than passed to the appropriate object/method to create the SEO URL.

I hope someone takes this onboard and actually treat this issue seriously rather than just dismiss it by saying that Google doesn't care whether something is a static URL with keywords or a query string parameter, because it most certainly makes a HUGE difference.

I'm not sure what you're on about. OpenCart already does all of this.

I'm sorry but NO IT DOESN'T.

The way OpenCart handles it is by using the tool/seo_url model and relying on data in the url_alias table.

If you look at how it does this you'll see that it's pretty much the most inefficient way possible, i.e. by executing an extra query for each qualifying URL... On a product list page where you're showing 30 products that's an extra 90 queries assuming a 2 level category structure. Let me say that again... 90 QUERIES. These queries are run UNCONDITIONALLY regardless of whether you have an url aliasing data or not. That's fine for a little mum-and-pup website that nobody ever visits, but it won't perform very well on a large website with 50,000 products and high traffic.

The much better approach to this is to actually have a url_alias field on the product, category and manufacturer records so you can pull the data out with a single query and pass it into an seo_url module for rewriting. On top of that it's also best to implement a default rewriting scheme so that there are still SEO URLs without having to manually write aliases. It's best that this is done when the data is saved so it doesn't need to be done on the fly. But basically what you do is take the product or category name, lowercase it, replace any non-alphanumerics with a dash and remove any consequtive dashes.

Also it's absolutely paramount to properly rewrite pages and some other common querystring params as that will get the best results in the search engines.

I'm not saying all this because I think OpenCart is crap, I'm saying it because I want to improve it to a level where it's usable by a serious online store, not a mom-and-pup shop and that's in everyone's best interest.

I'll see if I can contact Daniel to see if we can work on this together, as currently that's the single biggest thing that's a really big negative for OpenCart and I'd hate to rip apart the entire cart to fix all this and not have it integrated back into the core.

If your problem is with the url_alias backend there wasn't much need for all the other info. All that basically advocates OpenCart structure SEO URLs the way it already does.

I don't know how seo_url will scale on large sites. OpenCart is hardcoded to display only 12 products per page anyway. Your scenario could only happen on a default install if a large number of subcategories were set up.

No, the problem is not just with url_alias backend per se, but how seo is setup on the site alltogether, as there is currently no handling of some things I've described such as pages, which currently are still handled as querystring parameters.

Also the question isn't so much about the default install, but about OpenCart as a shopping cart system which can obviously be customized.

I guess from a business perspective it's actually better for me that OpenCart doesn't have good SEO as that is one thing that can differenciate my store from all others that are running on OpenCart (or another system for that matter), but since plenty of other carts have reasonably good SEO (although not great) it may as well be put into the core system to make OpenCart on-par with other carts like PrestaShop on Magento in this respect.

Sheldmandu wrote:No, the problem is not just with url_alias backend per se, but how seo is setup on the site alltogether, as there is currently no handling of some things I've described such as pages, which currently are still handled as querystring parameters.

Information pages are already SEO URL capable. Of the remaining pages only Home, Special Offers, Contact and Sitemap are of any importance (and I'd say very, very little at that; you should already have a sitemap xml file set up for bots).

Everything else should be actively blocked from indexing with robots.txt. There's no point in a search bot wasting valuable time trying to index your Account or Log In pages.

Yes, everything is loosely SEO URL capable, but not designed for a store with a large number of products. If you look at the url_alias table the query column by which the search is performed isn't even indexed. Do you have any idea how poorely this will perform when you have 50,000 products and hence 50,000 records in the URL alias table, even if you only have 12 products displayed on the page at a time...

I think that unlike unlike many other carts OpenCart is architected just right in terms of its complexity and hence easy of extensibility and what it offers, but SEO URLs (as well as perhaps lack of certain functionality, which ultimately can be quite easily added) are what makes it weak compared to other carts such as PrestaShop, nopCommerce and Magento. But, it is well architected without being over-engineered to the point where adding a little change requires changes in layers upon layers and lots and lots of files.

What I'm proposing is to make the appropriate changes to it so that it's the best in terms of SEO that it could possibly be. I'll probably end up building in the changes regardless, but I'd rather than go into the core, so both every benefits and my life is easier in terms of upgrades.

You keep flip-flopping on whether this is a backend code or frontend URL structure problem.

I have no idea how OpenCart would handle on a major ecommerce site in terms of speed. Some users say they've had good results with up to 20k products so far.

But while OpenCart might not be as optimized as it could be for large sites claiming it's "weak" compared to PrestaShop and Magento makes me think you're completely off your rocker. Those are both known to be slow even on small ecommerce sites, Magento notoriously so.

Seams to me this is should be in a different category

Anyway...
Whether OpenCart or any other software provides SEO friendly urls you can use .htaccess file to handle the job.

mod_rewrite, a beginner’s guide (with examples)

My experience with mod_rewrite is it can be sometimes troublesome depending on the server setup.

I do have to agree with the importance of this issue.

I would love to see OpenCart handle this like Website Baker, the mod_rewrite is done by the scripting for you no problems no mess and I haven't see a server it won't run on.

I'm not flip-flopping, the fact is that OpenCart doesn't have very good SEO URLs, and particularly the way that these URLs re implemented, which requires multiple additional round-trips to the database to look up how rewriting should occur. By being weak I'm not talking in terms of performance but in terms of SEO URLs. Although performance on a large site with many products under load won't be great given that OpenCart doesn't have any indexes in the database (separate issue, which needs addressing) and makes many un-necessary calls to the DB.

I terms of how SEO is done, yes, it's best to use mod_rewrite, but the problem is not just with inbound SEO but rewriting the generated URLs, which should be pretty easy to do by hooking into the Url class as well as making modifications in the SeoUrl and a few other places where Category, Manufacturer and Product URLs are generated.

It's also possible to do the rewriting completely in PHP, which although slower than using mod_rewrite might be a better solution as it means both foward and backwards rewriting will be performed using the same mappings.

Either way, SEO is certainly of uttermost importance for a shopping cart and what I'm saying is that it really needs improvement in OpenCart. I'm more than happy to actually implement it, but want to make sure it makes into the core as the changes require quite a few modifications to the core files.

Shelmandu, I'm totally on your side. BUT - let's not distract anyone from a stable version first.

You have valid points on both the SEO and DB Indexes. And offering to help sounds good to me.

The problem is there seems to be little in the way of a roadmap and these sound like a basis for V5. Neither are tweaks and it would be good for the entire community to discuss them with a goal of reaching some sort of near-term upgrade, without derailing so many who are simply waiting for a stable V4.x so they can move forward with projects.

I guess I don't get it. First you go on about how an SEO URL should be properly structured which happens to be (essentially) the way it's already done in OpenCart. Then you complain about pages that shouldn't be crawled in the first place not getting SEO URLs. Now we're on indexing - and really, how hard is it to take a minute to do that to the appropriate columns? - and seo_url.php being junked and replaced with "quite a few modifications to the core files".

Yes, you clearly don't get it if you can't understand how important SEO is and how important indexes are. These are basic things that should be built into a shopping cart from the ground up and should be considered basic necessities not potential enhancements for some future unknown version. Yes you can get away without indexes, but that means your database engine is doing ALOT of work in memory by basically going through every record, while if you have a b-tree index it uses a completely different algorithm which is far more efficient (this very much applies to the in url_alias table). It's not hard to do, but I assure you mum and pop don't know what indexes are to be putting them in place and then they wonder why something runs slowly.

I'm not complaining about pages that shouldn't be crawled in the first place, I'm saying that there are significant issues with SEO URLs in OpenCart in general and that's a fact. I don't know about your SEO knowledge and experience, but unlike many I know what I'm talking about and my site ranks No.1 in google for extremely competitive terms and generates well over a $1m a month in sales, because of a lot of time spent learning and implementing SEO among other work on the site, so I dare say I know a thing or two about ecommerce and shopping carts as well.

seo_url doesn't need to be "junked" as you put it, but what should happen is that the SEO URLs for products, categories and manufacturers should be retrieved at the same time as the rest of the data so it's done in a single query and there should be a default SEO URL scheme for handling URLs where an SEO URL hasn't been explicitly defined.

I'm not whinging here because I don't know how to do this and can't do it on my own cart, but because I think it's an important issue that should be addressed in the core. I've messaged Daniel and offered to help in this area, so we'll see where it goes, but with or without my help I think this should be addressed as a matter of priority ahead of implementing additional functionality, as SEO can make or break an online store.

sadly from what I've seen I'd say the chances of something like this making it into the official distrobution are slim to none

I've never seen someone write so much and say so little.

There's nothing wrong with the SEO URLs. OpenCart is capable of structurally implementing them exactly how you think they should be and many of us have already done so.

Database and code optimization - what you're really wound up about - is an entirely different issue. There's always room for improvement but anyone looking for an off-the-shelf solution for an ecommerce site doing in excess of $10 million in sales a year deserves the headache they're going to get.

there's no reason an OpenSource off-the-shelf solution should be inferior to a custom built solution or a purchased one. In fact, I've evaluated many carts in my time both OpenSource and commercial and can tell you that commercial carts are by no means better than open-source ones in terms of their quality.

From a developer perspective I believe the cart's architecture is the most important thing to look at as it determines how easily you can make modifications to it to suit your specific needs. It also makes absolute no sense to come up with an architecture from scratch, that's just a waste of time reinventing the wheel and will put you in exactly the same position if you were to take an open source solution and extend it.

OpenCart is indeed architected very well from a code perspective, it follows the MVCL pattern throughout, has consistent naming conventions, has a good DB structure that with application of indexes will work well for a site with many products and is not over-engineered to the point that making a simple change requires changes to layers upon layers of code. With a good architectural base a good developer or a team of developers can easily do whatever they want, and that's the reason we're going with OpenCart as the base.

What I'm doing here is pointing out that it needs a bit of work in a few key areas and asking how I can get these changes we make to make it into the core product, as I feel these changes could benefit all users and that's our way to give back to the project which gives our project a kickstart.

There are already, or have been, at least 2 other offerings of modified OC. Why not just make the changes you suggest and offer Shelmacart? I'll be your first user.

I'm not a big believer in the when in doubt fork it out strategy. I think it's best for EVERYONE that a single stream of development in maintained and one strong open-source project is better than 5 weak ones. I'd just rather we find a way to make these enhancements.

I have fixed the problem with the duplicate urls. It has no difrence to google or any other search engine if the url is like http://yoursite.com/product.html or http://yoursite.com/product

Correct, there's no difference to search if you do or don't have an extension.

You should however have proper rewriting and 301 redirection in place if you don't want to have duplicate content issues with google. I've had these before and they're not all that nice. And just redirecting to to the homepage is not good either as it means your page where you changed perhaps one letter gets scrapped out of the searh engine's index!

that's why it's generally good practice to stick the Id of the product into the url and perform all rewriting based on that.