my canonical urls don't seem to work

So, in other words, if the canonical URL is example.com/page1, if I enter that into my browser bar, the page is not found (404) or I get redirected (301 or 302) to another page? What does it mean "don't seem to work?"

Or do you mean redirects from non-canonical to canonical don't work? What is the expected behavior and the observed behavior?

Is Cloudflare causing whatever it is you're seeing? Maybe. Cloudflare does a lot of things.

It can behave as nothing but a DNS manager, it can block traffic it thinks is suspicious, and it can also minify CSS and Javascript.

I don't see how this would effect things, but it has effected how I access my cpanel and ftp (forcing me to login from their ip address).

Cloudflare is a reverse proxy service. The whole point of a reverse proxy is to intercept traffic before it hits the main server and serve up cached resources and, perhaps do load balancing. So when you say it has affected access to CPanel and FTP, that is expected and predictable. Indeed, that is basically the purpose and point of Cloudflare and all similar reverse proxy services (to put a layer between the user and the server that is generating non-cached content).

CF allows you to create a subdomain like direct.example.com that bypasses the reverse proxy. You can also temporarily turn off CF's reverse proxy for your main domain if you need to access your server directly.

Are there other services out there like CloudFlare

Several. Incapsula and Yotaa come to mind, but there are many others. Also, you can get many of the benefits by setting up your own reverse proxy on your own server and there is plenty of open source reverse proxy software if you wanted to go that route (though at that point you need to be running two servers).

that might not cause this problem

They're all doing basically the same stuff and they all allow you to choose which features you enable. The first question is what is causing the problem? It is going to have to be one of four things

- reverse proxy feature
- caching of static assets, including CSS And Javascript
- minification of assets
- blocking bad traffic

All of those can be turned on and off. So turn them off until things work.

"negatives is, my canonical urls don't seem to work"

We should not impact this at all. We don't do anything that would re-write or change urls, really.

"The developer of the addon claims that this is because of CloudFlare which prevents the service from working."
What are they saying? Is it a plugin? The only thing I can think of, without knowing more details, is that something like Rocket Loader may impact some JavaScript (if it is a plugin).

"but it has effected how I access my cpanel and ftp (forcing me to login from their ip address). "

We can't proxy ftp ports. You should be able to access cpanel and ftp by using something like cpanel.yourdomain.com or ftp.domain.com.

So, in other words, if the canonical URL is example.com/page1, if I enter that into my browser bar, the page is not found (404) or I get redirected (301 or 302) to another page? What does it mean "don't seem to work?"

Maybe I'm not explaining myself. The page is not missing. If it was just a page that has moved such as /this-great-article is now /another-great-article, that's a simple 301 redirect.

This is my issue. So, I tell a number of products and have my cart has categories and products within those categories. Now, for example let's say one category has 200 products and you choose to view 10 products per page, 20, 30, etc. The problem is Google is showing these generated urls as their own pages.

Case in point, I logged into GMT today and it said that I have duplicate pages. This was one example:

mycart.com/category/sub-category/
mycart.com/category/btec-category/?items_per_page=64

The problem is, the actual page is mycart.com/category/sub-category/. The whole ?items_per_page=64 is just an extension. It is still the same page, same content, same keywords, same titles, same meta descriptions, etc. So, Google sees his as duplicate content when it should not even consider ?items_per_page=64 or ?items_per_page=10 or ?items_per_page=35 their own pages.

I can't simply redirect or people looking to sort a category by 64 products or that category in particular, would not be able to, since it would just bounce them back to mycart.com/category/sub-category/.

Apparently, the canonical url addon is suppose to fix this. They say it won't due to Cloud Flare which somehow blocks this process.

What I just tried tonight - and time will tell if it works - if I went into robots.txt and put "Disavow /*?" I'm hoping this prevents GOogle from even looking at any extensions to urls such as ?items_per_page=64.

Disavow /*?

Hope this was just a typo and that you put "Disallow /*?"

I'm hoping this prevents GOogle from even looking at any extensions to urls such as ?items_per_page=64

Yes, this would block ANY query string (which is what you call "extension").

Is the ?items_per_page= the only parameter or could you have ?something_else= in URL that you would also want blocked?

Thanks @ aakk9999. Major typo there. :)

I did put disallow.