Welcome to the Q&A Forum

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.

If it were me and my client, unless it was a huge monetary purchase, I would just redirect it to the current domain. The reason being is that you can 301 redirect everything and the link juice is suppose to stay very close to the same; but why would you? Sure it might be easier for people type in the browser. But people already know the name more than likely. What I would do is redirect the new domain to the current domain. Then I would use the new domain in print advertising. That way you can really monitor how many people are coming from the print advertising (if the company even uses it).

But from everything I have learned when you change domains and 301 everything the traffic tanks for about a month or two. If this is ok, then it might be viable to switch.

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