Welcome to the Q&A Forum

Here is a tip that I use for my clients and I would recommend. Most CMS / Ecommerce platforms allow for you to put a category description in the page. But, what they do is when the page paginates is they use the same category description and just different products on the page (some use a querystring on the url, others use a shebang, others use other things).

What I recommend to my clients to escape any thin content issues is to point the canonical url of all of the paginated pages back to the 1st category page. At the same time I will add a noindex, follow tag to the header of the paginated pages. This is counter to what a lot of people do I think, but the reason I do it is because of thin content. Also you don't want your page 3 results cannibalizing your main category landing page results. Since no CMS that I know of lets you specify different category descriptions for each pagination of a category it seems like the only real choice. It also makes it where you do not really need to add rel=next and rel=previous to the paginated pages too.

One trick you can do is dilute the text pretty easily and make some small changes to make them compete with each other instead of one canceling two out like a duplicate content will get you. You could try something like this and it should be pretty easy to implement if you are using a template based cart system.

Shop 1 - Just have the normal product description on the page and all of the standard text you have from your menu, ect basically changing nothing.

Shop 2 - If your site is utilizing rich snippets, change them on a template level. Most work like this $template_variable So on the second site delete a little bit of the rich snippet data, say the condition and the manufacturer name. At the same time on every product page add a 200-400 word shipping and return policy. As the current standards are, that should dilute everything enough to look like a totally different page.

Shop 3 - Basically the same as shop 2, change the rich snippet data that is sent a little. Maybe it could be adding manufacturer data that is not in the other templates, or taking something else that is non essential out of the template. Then add in on the product pages a different but meaning the same 100-200 word shipping policy. At the same time either add in an "about" section for the manufacturer, or if you have too many manufacturers for this to be reasonable add in an about for your company on every product page.

By doing this you will make the pages compete with each other instead of making one page dominate. If you are using a template based CMS, the changes should be easy and should only take about an hr or two to do, minus the time to write the content.

I help moderate a relatively busy forum, sever hundred thousand active users, let me share some of our insights.

It sounds like you have links in posts being followed, no follow all links in posts no matter who posts them. For footer signatures, make a threshold, say 25 posts before the user can have a footer signature. If you want to give people more incentive to post, have a do follow link in their profile after a certain threshold has been passed, like Moz does.

Fighting forum spam is a full time job almost, but it is easier to beat it in the beginning than just handle it as it comes in. Create a honey pot on your registration form and change it out weekly. Something like this could work, http://solutionfactor.net/blog/2014/02/01/honeypot-technique-fast-easy-spam-prevention/

As for the links on the other sites I would disavow them, but once you stop the spam, they should stop. What they are doing is called link laundering. They are placing a link in your forum, then they are using a service like fiverr or similar to build backlinks to the forum link. They do this in hopes to raise the authority of the forum post and in turn raise the authority of links pointing to their site. They are pretty insulated from penalties by doing this, but they risk you getting a penalty.

The only way that it could work that I can see is if Njoyn allows the use of cnames. Then you could cname the domain to their portal.

I am guessing that the form is using a link instead of a button. The simple solution is to edit the link that the form is using and make it a no follow link. Then the crawler will not try to follow the link and submit the form.

I do not think a plugin can do that, but I could be wrong. I would look into modifying the theme.

One sneaky trick that your competitors don't want you to know about...

I could really use that headline with this. Imagine things this way, you are doing backlink profiling on a competitor that ranks above you. You see that he has a bunch of spammy forums posts. But no matter what you do, you cannot out rank him. So you start forum spamming yourself to try to catch him in the SERPS. But then you get a penalty.

The disavow tool has more than one use really. It will let Google know not to penalize you for links (or give you credit) but it will also mask your link profile too. I would just disavow them and be done with it. Let you competitors try to figure out what Google is giving you credit for or is not.

In most carts they aren't an actual add to cart per se. They are link to the product that uses ajax or a query string to add the product to the cart. So basically if people enter in through that link they will have the product automatically added to their cart. I think most people see that as bad e-commerce practice. Plus it really would make it hard to do any evaluation on abandonment.

I personally always make them the same as the product title. The title of the product should 99% of the time describe the image very well, and the way that most ecommerce platforms are set up it can be done relatively quick for the whole site too.

I don't think that can be had for the price. I pay around $260 for a single xeon with a ssd and 8 gig.

I don't know if you have checked it out, but here is a great guide for getting started with Moz, http://moz.com/help/guides/getting-started  Also like Malcom mentioned, the forum is a great place to ask questions that you have as well.

I am having a hard time understanding how Google will deal with this scenario, I would love to hear what you guys think or suggest.

Ok  a category page on the site in question looks like this. http://makeupaddict.me/6-skin-care  All fine and well, But a paginated page or a filtered category pages look like these http://makeupaddict.me/6-skin-care#/page-2  and http://makeupaddict.me/6-skin-care#/price-391-1217

From my understanding Google does not index an anchor without a shebang (#!), but that doesn't mean that they do not still crawl them, correct? That is where the issue comes in, since anchors are not indexed and dropped from the urls, when Google crawls a filtered or paginated page, it is getting different results. From the best of my understanding, and someone can correct me if I am wrong but an anchor is not passed in web languages like a querystring is. So if I am using php and land on http://makeupaddict.me/6-skin-care or http://makeupaddict.me/6-skin-care#/price-391-1217  and use something like .$_SERVER['SELF'] to get the url both pages will return http://makeupaddict.me/6-skin-care since the anchor is handled client side.

With that being the case, is it imagined that Google uses that standard or is it thought they have a custom function that grabs the whole url anchor in all? Also if they are crawling the page with the anchor, but seeing it anchor less how are they handling the changing content?

I think that is the exact opposite of how security works. But once installed and the site is properly configured you should never have an issue with anything. I just wish more were renewable instead of having to get re-issued.

Close, but look at Googles certificate, http://i.imgur.com/Lw1rlH4.png  They are actually a CA now after the issues they had with their certificates before. I think they became a CA when they rolled out the tougher encryption. Soon, I imagine they will start selling them to the public like they do with domain names.

I guess the main question about your other tests is did you check to see if the server was utilizing mod_spdy? That is what my whole argument centers around. Serving https up without it is way slower, I realize that. But if the server is running mod_spdy and the browser supports it, it will be just as fast. Just as a point of reference cUrl and no linux only browsers support spdy. Only the main stream chrome, ff, IE, safari, and the kindle browser support it.

I think you are missing the point a little bit. Say you get shared hosting at any provider that I can think of, or say you get a vps, or even a dedicated server. 9 times out of 10 what you are getting is a machine running either WHM or Plesk that is running php 5.4, apache 2.2 and mod_php, and current version mysql. You are getting a slow set up basically. I have dealt with dozens of hosting companies in the last 6 months and I cannot tell you one that has set up mod_spdy on a default deployment. It just has not made it in the standard yet, it is like mod_pagespeed, they rely on you to set it up. With a setup like that, yes, https requests are going to be slower, there is no doubt in that. BUT, that is not what I am talking about running on. Set the machine up running php 5.4, use an apc caching layer, fcgi as an interpreter and install mod_spdy (I don't use mod_pagespeed, I optimize from the start) the same machine can quadruple the requests it was taking before.

I don't know how familiar you are with how http or spdy works, but here is a brief overview. On a server without spdy enabled when you request a page, the browser will make a connection (establish an insecure handshake) and the server will deliver the page. As the page is loading the browser will scan it for resources that it needs to load, then it will start creating a handshake for each resource and then start downloading it. The browser has a max of 8 channels that it can download at once. So if your page has 5 css files, 8 js files, and 30 images, it can only download 8 of those files at once, it creates a que. When one finishes, the next starts. Where all of your time is really ate up is the handshake for each resource.

With spdy the way it gets around this is there is only one handshake (for either ssl or http) in that handshake it sends all of the resources at once. When your browser scans down the page and starts asking for resources no que is created, they are all sent as soon as they are asked for. That is how it is faster, it reduces connections, think of it as a super keep-alive.

I totally believe that you didn't modify the timings, but you cannot use that as a test. The main reason being that one of two things could be happening. Either your isp has cached the content for the page or Google is edging with them. When you run a https request it bypasses caching and edging. So technically if you were someone like Google or Amazon, it could slow your site down. But like 90% of other people that are single location hosting a site without using edge servers all requests are leading to the same place. Plus you have to factor in network integrity. I have a site launching at the end of the week that will have about 10k users on it at any given time during the daylight hours in the US. We didn't just ramp up the load tester to 10k and call it a day, we have had the thing running since Monday non stop with 15k users on it to see the weak points in the network. We are transferring almost 2tb an hour on our AWS instances to see if the database is going to fold or not. Before we installed mod_spdy (we are only using https on checkout and contact pages) we were spawning way too many frontend instances, 9 if I remember correctly. With mod_spdy we have reduced them down to about 6 with a 7th firing up every now and then, just depending on where the wave of the load goes on the site.

Read this, http://research.microsoft.com/pubs/170059/A comparison of SPDY and HTTP performance.pdf

The only time that http is faster is when mod_pagespeed is run and you are pipelining. Most US isp's do not support pipelining, so the only real option is using a spdy layer, hence why it was created.

I set up a lot of high traffic servers, everyone of them relies on mod_spdy to serve requests because it kills over http1.1. Most sites don't use mod_spdy, most servers do not have it set up, so that is my basis for the myth. If you look at the test results running spdy with ssl is faster than apache running http1.1, which accounts for I would guess at least 70% of all *nix machines on the net.

As for security I agree that setting up SSL certificates wrong is an issue, but that does not mean that there is an issue with using SSL. It is like if someone does not lock their door and someone breaks in the house, it was not the lock's fault. I set up ecommerce site's and boxes for a living and do quite a bit of pen testing, there are not many attacks out their where someone is on a closed non public network that will actually work in the wild. I mean some of the things you list could possibly work, but in most cases it would be easier to drive over to someone's house and torture them to get the information than to try to hack a router at a CA.

I think that is one page you don't have to worry about using SSL on. I think the point of many people using SSL is because of them

SSL doesn't slow things down, that is a myth. Sure if someone is using an outdated browser it will, but loading all of the shims will slow the site down to so the difference will not be noticeable. Run SPDY on your server and you can test it for yourself.

As for a man in the middle attack, that has no SEO bounding. If I am running SSL on my blog that only serves articles with no login, I am not to concerned about a man in the middle attack. An injection type attack maybe, but http is open to more than a SSL site is.

Let me address this on two levels, first being that unless your agency has hundreds of guys and is willing to develop a year into dev with them, you will have a hard time stacking up against the competition in so many aspects. Take Magento for instance, do you know how many years of security their are in it. How many bugs have been found, how many hours it took to get it to where it is.

Now for an answer to your question (I specialize in e-commerce and SEO related to) so I will give you the things that the platform I use does not have that I would like.

• The ability to easily set category paginated pages to rel=canonical the main category page
• The ability to easily set any page to a no-index
• The possibility for category pages to be able to use different descriptions per paginated page
• Backend editable robots.txt and htaccess
• Extreme analytics. Something like can be done with segment.io, where you can see a users real name, what page he landed on, what pages he looked at, whether he bailed out of the process and where he did. Sure you can do this with GA, but you cannot associate a name with them, or you violate TOS. I want to see that John Smith landed on my widget x page, then went to my sprocket page and came back to my widget page. Then he went through the checkout process and bailed out on the shipping step. I want people to be able to call John and ask him if there was a problem and know real information about him.
• Variables for everything. If I want to have a different title tag on an image than the alt tag, I would like some where to enter it.
• Good adwords integration, this can go great with the extreme analytics.
• This kind is covered by the other one, but really good stats, I want to see what products are popular in what countries, what products are popular, break it down by age if I require someone to enter an age on the account form, and sex too.
• Built in review engine that is a mix of trust pilot and yotpo. I want to automatically mail people for reviews, then I want to post the reviews to google automatically.
• Also easily export data for google trusted stores.
• Might as well have an export for google shopping as well.
• I would like to see it hook into Moz and Raven's api. How handy would it be to look in a back office product list and see a row of icons telling what needs to be adjusted SEO wise with a product. You can see at a glance which ones are duplicate or which ones have meta issues.
• Have a dashboard for Moz and Raven as well, where you can see mentions and things from the sites back office dashboard.
• A grade on demand button in the product page could be pretty awesome too, that used the Moz page grader.
• The ability to convert normal search pages into top level landing pages complete with the ability to change on page components.

This is what I can think of off my head for the moment. It seems every day I have new feature ideas.

Invalid code does not equate to slow code. Google used to purposely not close html and body tags to save bandwidth and loading time. I took the question as meaning w3c valid code.

As long as links are not broken and resources are not returning 404 errors, my understanding is that it is not affected at all. The only thing I would make sure of is that fetch as google returns the page looking like it should. Here is a video from the authority on the matter.

https://www.youtube.com/watch?v=j3KgrbiB1pc#t=52

How many products are you going to have? Depending on your url structure, you might think about using the word buy instead of product or shop, so your urls could be buy/fancy-health-product.

I wouldn't for the cart and checkout, I would actually no-index them. The reason being is depending on what measure you are using for cart abandonment, having people land on those pages will skew your results. Also at the same time there is no good reason for them to enter on those pages so it will increase the overall bounce rate if people are entering on them.

Privacy policy, shipping, and return policy, I would not specifically no-index them, but I would not try to optimize them for anything other business name - page name. That being said, if you are like Costco and offer some amazing return policy that someone can return a product after 10 years for a full refund and it is a popular product; I might consider optimizing the return policy for that as well. Or if you are the only person that offers free international shipping on a large item like a baby grand piano or something. But if you fall in line with the rest of the industry I would just leave them as is and only optimize them for your business name - policy type. So then if people search for your business and return policy those pages will more than likely come up.

Ok this might help without changing any code really. The way most templating languages work is they preserve spaces and returns between statements so they can be formatted correctly. Just put your code on one line like this

{% if current_tags %} {{ current_tags | join: ', ' | capitalize }}{% endif %}{{ page_title }}{% if current_page != 1 %} – Page {{ current_page }}{% endif %}{% unless page_title contains shop.name %} | {{ shop.name }}{% endunless %}

With no spaces in between. Then test it, if everything is run together just a space between the variable. But that should take out the hard returns and return your title tag on one line like normal.

Why you say panoramic, do you mean side scrolling? If so, you should be in the clear, Google is ok with that. People for years have used negative positioning with sliders and the content associated with them and it gets indexed just fine. The if the site is utilizing parallax side scrolling and is pretty much a single page site I think you will have the issues more closely related to getting a single page site to rank.

The post by Tiffany is correct, but most crawlers like moz work on string length. What the issue looks like is that the template is sending out a lot of white space that is being counted in the string length. Where this comes into play and why it is not noticeable is this. In html if you have two spacebar spaces, it will only render as one space in viewports. But in the code you will still have the two spaces.

The best solution to fix what you have would be to try to attach a filter to your current code, thus reducing the number of blank spaces and line breaks. Can you past what liquid code you currently have to generate the page title and I might can work something out to test. I haven't used liquid before, but it looks close enough to smarty that I might could work something out.

What platform is the site developed on? Does it use an internal system to write friendly urls? I have seen a couple that when they write the page they send a 302 header because a bug or lack of understanding from the developers end.

On the 3 pages, how many of the products are the same? Is MOZ's crawler picking them up as duplicate content?

Yes, there is a schema for brand. It does need to be inside a product though from my understanding. You can find out more information about how to use it here, https://support.google.com/webmasters/answer/146750?hl=en  Also note you can nest organizational info into the brand name as well, so not only can you have brand you can information about the brand.

I totally agree with EGOL on this. I would like to add my 2cents since I think I am one of the only SEO people that is a developer too.

This is what I would do (in pseudo code) put a <rel="canonical"  href="$url=strtok($_SERVER[" request_uri"],'?');"=""> </rel="canonical">

This is in php, I don't know what platform you are on, but what it will do in php is return the current url as the canonical and delete the ? and everything after. So basically it will return the url minus the query string. I use this technique a lot with my clients for doing canonical urls on CMS's that use query strings and it works great.

I don't think they look at them negatively, but it will dilute your overall keyword in the url ranking. Also it might get you some weird classifications for your pages too. Like say that your string on one page happened to be the model number of some product, or a mpn of a product. It might make that page rank for something totally un-intended.

Personally I would either teach them how to use Wordpress, or just get them to send you a word document and charge them for posting it. The on site blog is going to be better for SEO.

I agree with the other poster, just use one url for each product, don't create pages for each variation. The content will be a nightmare to try to write, especially from the time > gain aspect of things. One option you have is using a shebang to determine which product is selected in the page. Something like

Link to hardover book

site.com/book-name.html

Link to paperback

site.com/book-name.html#!paperback

Link to ebook

site.com/book-name.html#!ebook

ect.

That would be what I would recommend to a client and have them use. Then you can canonicalize at the url without the shebang, but still offer the variations and have links to the variations.

I don't think that will work. The reason being if I am understanding correctly, is that the canonical url will never be accessible. I don't know all of the specifics about what Google does on an internal level (like most SEO people) but I don't think it would fly just for the fact that the canonical is never able to be accessed.

Are redirections and htaccess issues the reason you cannot move over to using a sub directory?

I have never used it, but I have heard a few people mention that they like it in local meet ups and things like that. For a blogging platform you are not going to get much better than wordpress. It might have the problems that wordpress blogs normally have with some of the indexed pages, but those are easily solved. The good thing I hear about the module is that you are running a full featured wordpress installation, not a sandboxed type. So it is basically like running wordpress with a magento connector.

Does the platform you are using let you select a default category for the product? Several platforms will let you select multiple categories and make you chose one as a default category. If so, you can just work off the uri of the page and insert the default category as the canonical category in the rel=canonical.

Sorry about not being clear on the dev. PrestaShop is totally OSS like Magento or Wordpress. So generally what we do is take a spec from a client, see if their are modules commercially available for the functionality they want. If not, we just figure in developing them from scratch. I think how most people do with a site of that magnitude.

As for the really believing in PrestaShop, I do. It might not be the best situation, but I do have all of my eggs in that basket and I hope nothing bad becomes of it.

Totally reasonable, I didn't really know that existed, but it is changed. Sorry for the confusion. Also, like I mentioned I am just a company that uses the product, not someone at the company itself. I do contribute on the blog every now and then too. But as for some links for reference, here are a couple

Magento's forum closed

http://www.magentocommerce.com/boards

Magento Closing products

http://techcrunch.com/2014/07/03/ebay-owned-e-commerce-platform-magento-shuts-down-services-aimed-at-smaller-retailers/

Like I mentioned above I am just mixing the on the record facts, with what I have heard from some insiders. It could be wrong, it could be right. I know because of the nature of is talked about here we all have to do a little bit of speculation because we are generally discussing systems and companies that we have no direct control of.

But like I mentioned above I can totally see how my name and the posts created a misleading environment and I have changed my name.

I see how I could have raised some ambiguity  about what I am doing and what I do. The truth is I signed up for a Moz account a few years ago and never converted the trial. Then I decided to try it again and converted over to a paid account. When I signed up the first time I used my company name dh42, so the second time I was not allowed to use that name it was taken. So I chose Prestashop, I did not realize that it would end up being my forum posting name at the time. But I am no more affiliated with Prestashop than you are with Wordpress, I am just a developer that uses the platform, nothing more. I don't have  any paid modules or themes for them, I get 0 compensation for them other than what I charge clients to develop sites with their software. But I can totally see how my poor choice of nick leads to believe otherwise.

I think Target ended up having to pay around $100M to get things straightened out after their breach. But at the same time their breach was different than an online store breach, it was a hardware level breach from what I understand. But also their transaction amount is a game changer for fines and penalties as well. When you compare 2 stores and one might do 1 million a year vs the other might do 50 billion the rules are different, contracts are negotiated differently. Target might even run their own clearing house, I honestly have no clue how it is working on their level.

But as for it being the hip thing to do to ward against Wordpress that is totally not where I am coming from. I run Wordpress for my site. Let me give an example, there is a company that does a lot of PrestaShop development that I know, they recently did a redesign of their agency site that does not sell anything. They used PrestaShop as the CMS to run the site. I find that weird that someone would use an ecommerce platform for a static site with no products. I told them that at the time. I still think Wordpress would have been a better solution.

What it comes down to in my mind is using the best tool for the job, not the best tool that you know how to use.

I don't know about your Wordpress installations, but with mine, before I started denying by ip on the wp-login page, I would get hundreds of bot connections and login attempts a day. So much so that some of the smaller sites it would be 80% of their monthly traffic. People run bots like this all the time. Those are the people that I think have enough time on their hands. All they have to do is check a config file on the server, like pull a fileexists on say wp-content/ecommerce-package/img.jpg, if the file exists then start the brute force attack. Just like bots are set up around timthumb flaws, I would be willing to bet that there are people that set them up around other flaws as well.

I just have the opinion that Wordpress is inherently insecure on a lot of levels, not just the login system. If you look at any major platform, Magento, Shopify, OS Commerce, PrestaShop, ect, they all have a few things in common. They use a real MVC that separates code from templates, they all have two login systems, they have a module system that extends, not adds functionality. They are built with an ecommerce security minded focus, not an ease of use ease of extension focus.

But I would like to reiterate that I am sorry about the confusion with my name, it was just a poor choice to chose and I am not affiliated with PrestaShop other than being a developer that uses their platform.

I hate to be that guy, but the responsible dev practice in this situation is to not use Wordpress as an e-commerce platform.

As far as platform everything is relative in cost. I can set a site up using PrestaShop for close to the same in cost as a site using Wordpress (I am shooting off the hip at what a general Wordpress e-commerce site would cost, but I am thinking 3-5k range just as far as time involved) Sure I do shops that cost 10 times that much, because they want custom features that are not part of the stock package.

But lets speak on robust security and the cost of it. Say you create a site on PrestaShop and one on Wordpress. Say the PrestaShop site costs you more, just for sake of argument. Say 50% more.

Then say the sites are pretty basic sites, they figure shipping manually in an easy way and they use Auth.net for processing transactions.

Both platforms have a auth.net module for their ecommerce integration. But with Wordpress, who made the module? How secure is it? The PrestaShop one is developed by Auth.net and PrestaShop and has went through a 3rd party security analysis and testing.

The default Wordpress login system will let you try as many password combinations as possible to get logged in. You can download and install a module like wp_better security to limit that though. But on the front end of an ecommerce site, how do you set that up for UX? If you lock people out of the site, you might miss sales. You would manually have to manage it, or just disable it, because it might be problematic if you have a site that has 1000 purchases a day, you might be spending a couple hours a day dealing with manual password resets and ip white listing. So I would be willing to bet that most merchants will either write a really lax rule or disable the module after a while, it will just cost them too much money. Since Wordpress uses the same login system for the regular customers and the admin, then it will leave the site open to be cracked on an admin level. But there is always the possibility that someone can create a privilege escalation attack too. Then a regular user's access has been escalated to a SU or Admin. But your site does not store credit card info, because you use the AIM method for auth.net, so they are not really going to get anything. OR are they? If it was me, I would just write an override that processed orders as normal, but at the same time printed the CC info to a text file. Then you would be none the wiser.

Most CC issuers like Visa, Mastercard, ect charge about 10k a month for non compliance with PCI standards, that 50% dev cost can be mitigated real quick with a couple fines levied your way.

The security issues with Wordpress are real. It was never designed to be an ecommerce platform, it lacks the security. One of the major security points is the login system. Wordpress only uses one login system, while most ecommerce applications use two. This means you are really open to a cracking type attack. One basic security principal is to never store your admin's in the same table that regular users are stored in. That way, if someone does crack a password in that table, all they will see is 1 user account information, not have control of the whole shop.

Plus you run into the lack of features as a security issue too. Sure you can extend the features with plugins, then you have code written by who knows who, code that might not be secure or might have back doors in it. It is just a bad situation.

Not to mention that the way the templates are written is a huge security risk as well. Wordpress has executable code in the template files. That is how their templates are made. I cannot thik of another ecommerce platform that does this. It kills the whole MVC principal which is built on scalabilty and security.

Google Webmaster Tools has that built in. That is the only one I am familiar with.

They have had a paid model for a while, it is called enterprise edition. If I remember correctly licenses start out around $14k a year. But at the same time I don't use Magento so I could be totally wrong, I just remember looking into it at one time and thinking it was too high.

PrestaShop is a good open source package. It is what I use.

But again I would just like to say these are rumors I have heard about Magento, they just seem true since they are shutting so much down.

Just a note on Magento, there are a lot of rumors that the CE is going to be discontinued soon. They already announced they are dropping 2Go and another business product. They closed the community forums a couple months ago, I have heard several rumors at events in the industry that they are going to a paid only model.

I think the canonical tool I would use would be GWT. If it is in there and it is bad, disavow it, Moz crawls on it's own, and does not use any of that data. The basic thinking I have is that you are wanting to make google happy, so you use the resources they have.