"Your shopping cart is empty"

[mc12345678]

Well, if you plan to keep SSL disabled (at least until the issue can be resolved) then that section will need to remain commented out.

The other "thought" and as related to the thread recommended above, would be to disable SSU which should be possible within your configuration menu area. By temporarily disabling it while the store is set to support SSL (whether the htaccess rule is enabled or not), you should be able to navigate the store to add a product (using default ZC URIs. And see if the problem is more of a server configuration/interface with the server or if it is/was the uri rewriter.

After the test you can return to whatever status/condition you think appropriate for your needs and the operation of your store. Certainly the inability to add items to the cart will have a direct impact on the ability to make sales.

[campdave]

Thanks, there is a config section in the admin panel for SSU, but it doesn't seem to be a simple on/off. I did comment out some of the lines in the htaccess file which also seem to be part of it, as when I did so the links reverted to the normal product ID, but when I clicked on them I got a 404 so there's something else I need to find somewhere.

[mc12345678]

Thanks, there is a config section in the admin panel for SSU, but it doesn't seem to be a simple on/off. I did comment out some of the lines in the htaccess file which also seem to be part of it, as when I did so the links reverted to the normal product ID, but when I clicked on them I got a 404 so there's something else I need to find somewhere.

That's unfortunate. Both of the other two suggested/recommended uri rewriters have such an on/off switch. When off the htaccess can remain created or can be removed (at least the parts created to support the renaming).

So, here's another thought if you're up to it at least a little bit. If you were to create a new store off of your current host that has only the default product with SSL activated and see if that version of the store can handle such a connection properly, then it would at least help eliminate the server's SSL configuration as part of the issue.

[campdave]

After finding the documentation, I did actually find an off/on switch for SSU which wasn;t labelled especially well in the admin panel.

Turning it off and reinstating SSL seems to have fixed the issue on both IE and Chrome on my laptop in both standard and private browsing. Unfortunately it means my links from search engines to my site no longer resolve correctly, but that will sort itself out the next time google spiders my site.

I appreciate different people have different views on the subject, but would you recommend trying a different package to create more search engine friendly URLS - do you reckon it makes a difference to SEO?

Thanks for your patience in helping to solve this problem for me.

[mc12345678]

Bravo.

So, agree, there are the sort of "two schools" of thought. Don't use a uri rewriter, do use one that works...

I have a preference, but it's somewhat a "selfish" reason in that, if I was going to rewrite uris, then I would want total control of the result and not something that follows some certain set of rules that I have to code/recode in order to get to work the way I want them to work. But, on the flip side, having a relatively automated method of not only generating but more than likely being able to handle a user's inability to spell well may also be of benefit...

If you have/or want to maintain the exact same uris for all of your products (for now), I would say/suggest CEON (SEO) URI mappings. If you want a system that seems to be similar to what SSU offers then I would suggest Ultimate SEO URIs (usu is one way of how it's referred). It is likely to be a little more straight forward in transition from SSU to another URI rewriter.

There are settings with which to be concerned, and I believe there is plenty of documentation and there is a forum thread for it/both programs.

The thing is, that generally speaking, only one or the other rewriters is suggested to be installed at one time and having two or more could be problematic. CEON does offer the ability to be installed and to be able to obtain information from the existing program (SSU) to help populate CEON to take its place, but when all is said and done, only one should be installed.

There have been those that have continued to suggest SSU, but of any systems to which I've seen it installed, it has not functioned fully/as if no rewriter has been installed because some feature or another has been disabled or there continues be more and more error logs...

[schoolboy]

After finding the documentation, I did actually find an off/on switch for SSU which wasn;t labelled especially well in the admin panel.

Turning it off and reinstating SSL seems to have fixed the issue on both IE and Chrome on my laptop in both standard and private browsing. Unfortunately it means my links from search engines to my site no longer resolve correctly, but that will sort itself out the next time google spiders my site.

I appreciate different people have different views on the subject, but would you recommend trying a different package to create more search engine friendly URLS - do you reckon it makes a difference to SEO?

Thanks for your patience in helping to solve this problem for me.

I've never been a great fan of URL re-writers, but these days there are some operational reasons for using them. About 18 months ago I installed CEON URI Re-writer, and it's doing a good job. Bear in mind that it hasn't been "tweaked" for some time, and with Connor's sad passing a few years ago his superb skills have not been "replaced" - despite the noble efforts of many people.

I made some alterations to the mod before installing it. For example, it applies latin-1 collation to the new tables, so I changed this to utf-8.

Also, it still offers the selection to re-write url's for tell-a-friend and reviews. So after installation, use the configuration options to switch off this capability.

The mod allows a variety of automatic and manually controlled URL re-writes, with the resultant url being stored in the database. One down-side on installing into an existing store is that you need to "manually" edit each existing product for the mod to generate the URL.

I circumvented this by applying SQL injects, after creating my desired URL's in a MS Excel sheet, based on a dump from Easy Populate. What would have taken the better part of 2 - 3 days, took just over an hour.

Now... The "practical" reason for using these re-written URL's...

Firstly, there is no evidence to show that a re-written URL has a measurable SEO benefit - but what we have tracked is that as the URL is often reflected in the search result (and I'll elaborate on this later), PEOPLE see their search phrase repeated more often in the search results. This is a basic marketing principle and comes down to human behaviour - but there is a greater likelihood that a search link will be clicked if the person seeing it gets a good idea of what it points to.

Now... to elaborate... If you use AdWords, Google offers an opportunity for you to insert 15 characters into two "path" fields for any given display advert. It does not generate a hyperlink, but appears as the "green text" under the advert's heading. Again, having textual url's makes this more logical and again, repeats the display of actual words that the PERSON is keen to see.

So, what I have done (and you can "edit" the hyperlinks in CEON) is configure URL's that have a path of two elements:

EG: http : // yourwebsite . com / first-path-text / second-path-text

... and keep each path to 15 characters or less.

This takes a bit of careful planning, but if it becomes a "policy", then one can apply when new products are added.

The RESULT (and again... it's not about technology but HOW PEOPLE BEHAVE) is that it returns results to the screen that are far more likely to be "noticed" and "acted upon" by the viewer.

When one couples this with ad extensions, and the Super-Data plugin for Json/ld Structured Data embedding, one sees greater CTR, and... and... and...
more rapid climb up search results tables.

We launched a site in mid-November... already 30% of our important keywords are resulting in ORGANIC links on page 1 of google (desktop) and nearly 40% are featuring on page 1 in mobile searches.

[schoolboy]

Critical to managing how google interprets the site, are good use of Google Search Console and Analytics. These services need to be very carefully configured and "linked" (also to any adwords and merchant-centre accounts). Enabling enhanced modes in Google adwords, and configuring all the essential technology, one can test how effective your efforts are by using a variety of measuring tools. These include:

Google Pagespeed Tester
Google mobile tester
GTMetrix pagespeed analyser
Google Structured Data Testing Tools

If you get bad reports, or score under 80% on any of the tests, your site needs work.

[campdave]

Thanks both for your comprehensive replies.

It's a major regret of mine that I didn't put enough effort into SEO when I started my site a few years ago and got to the point where I have 2600 products that may need updating.

Obviously I'm apprehensive about installing another extension which may or may not conflict with SSU and more importantly, could reinstate the error I was having - so I think any solution needs to be a mapped solution rather than a re-writer. I guess rather than rushing into it, I should see how my rankings are affected once google reindexes my site back to it's original URLs.

Plenty for me to research and think about. Thank you!

[schoolboy]

What I did - 18 months ago - was launch an entirely new website on a "fresh" install - using a "clone" of the database (with lots of php-my-admin editing along the way).

But I ended up with a site that was populated with all the original site's product and attribute data, shipping and payment configs, customer and transaction data - but no complex plugins or "dud" database tables and fields. Then, we installed CEON and (as described in my earlier post), we "applied" the new url's with sql inserts.

The result was one site (the original) using conventional dynamic URL's and the other using URI mapping. Both were functioning side-by-side in the real world.

So, it mattered not if customers accessed either site to login, but what we also did when they used the new site for the first time, was send them a message telling them that their login on the old site had been deactivated, and that all future purchases should happen on the new site. After 6 months, we switched off the old site and did 301 re-direct (global, using .htaccess) to the new site.

Interestingly, the effect on sales (across the board) was positive. We lost very, very few customers, but ended up with a relatively "seamless" (if slightly prolonged) transition, with no down-time.

[campdave]

That's a good suggestion, and one I will seriously think about. Thanks very much!