Welcome to the Q&A Forum

I don't think I would do it this way, RWesley.

Why do you need both versions to be live and indexable at the same time? Most of the time people use a development environment for this type of thing.

I guess I'm a little confused about the strategy here. Could you explain more about the reason you don't just do all of the work on a non-indexable, private development site and then push it out live to replace the existing site on www. whenever it is complete, along with the redirects from old content URLs to the new ones (if that's even necessary; which it is not if you're replacing old content on the same URL).

Those are indeed a very different type of review than what Google is probably used to parsing. Have you tried changing them to "Ratings" instead of "Reviews" ?

Thank you for sharing the GoDaddy response with the Moz community Andrew.

How many (and which) pages/links is this affecting? Once I know that I should be able to help a little more with prioritization. If this is the way your navigation menu works, for example, then it's a 10. If it's just happening on one page that doesn't have a lot of external backlinks it's a 1.

Google says they follow redirects at least five levels deep and that they treat 302s and 301s the same. In my humble opinion after seeing numerous examples otherwise, this is B.S. It can depend on the response times, how the redirects are implemented, how much trust Google has in your site, and many other things. Long story short, fix it if you can, but I doubt it's going to require switching hosts.

Barrett,

I think the Car Gurus way you laid out above is a great solution. This allows you to scale content as well, since now you can provide content only on the single canonical zip code page for that "area". What are some things that Los Angeles drivers need to know about buying a new or used vehicle? Is there anything specific you can call out, like "The last thing you want in LA is to be stuck in traffic on the 405 with a car that won't start..."? If you can pull in data about the zip code it may be possible to automate some customizations at scale as well, such as the average price of new and used vehicles in that zip code, which vehicles are the most popular in that zip code, etc...

Either way it sounds like you're thinking about the problem in the right way so I'm sure you'll be successful. Good luck!

That is a very interesting setup by Auto Trader. The Rel = "Canonical" URL changes on the true canonical page depending on your location. So this URL:

https://www.autotrader.com/cars-for-sale/New+Cars/Nissan/Rogue

May canonicalize to either of the URLs below, depending on your location:

https://www.autotrader.com/cars-for-sale/Nissan/Rogue/Denver+CO-80211

https://www.autotrader.com/cars-for-sale/New+Cars/Nissan/Rogue/Los+Angeles+CA-90001

Technically speaking, I think it should work the other way around. Their rankings for these geo-specific keywords seem to be pretty good so I can see why it may be tempting to emulate. However, keep in mind that Auto Trader has a TON of brand equity and PageRank so they can get away with things that might harm another site either now, or in the near future.

After speaking with two other colleagues just to verify, my recommendation here would be NOT to do this. At best, these canonical tags on Auto Trader are probably just being ignored by Google.

Hello yacpro,

I would recommend providing a link directly to the top-level "Jackets" category for users. Maybe I don't know what type of jacket I want to buy? As for search engines, that's probably too competitive of a short-tail phrase to compete on, but at least the page will provide direct access for spiders (and users) to get to all jacket categories.

There are a number of ways to handle this situation. Rest assured that you're not going to get "penalized" by Google for this. Every hardware and parts maker, whether it's auto, home improvement or replacement parts for appliances -- is dealing with the same thing. Here are some choices you may have considered:

1. Choose a canonical version and canonicalize all of the others to it. This means each one is a separate product that can be found on the site, but Google will only show one of them in the search results. There are obvious cons to this setup, such as being less likely to rank for specific long tail queries related to the make/model.

2. Keep each one separate and self-canonicalizing. Rely on Google to figure out that they're not the same product, and to show the most appropriate one for each query.

3.Combine them all into a single product page and use drop-down selectors to choose make/model or whatever other variants are available for the product.

Which one of these seems best for your situation?

Hello Hijabgem,

You should NOT have more than one Rel = "Canonical" tag per page. However, as is the case with the page below, if the tag is the same URL in both instances on the page it probably isn't going to cause any problems:

| rel="canonical" href="https://www.hijabgem.com/maxi-shirt-dress.html" /> |
|   | rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" /> |
|   | rel="canonical" href="https://www.hijabgem.com/maxi-shirt-dress.html" /> |

Hello ImpericMedia,

If you can share the site with me (private message is OK) I'll look into it. If you don't want to do that, here are some things I would look at:

1. If you have verified that the Robots.txt file is not blocking the pages you want indexed, and the pages are still not indexed (or indexed with a message about the Robots.txt file) you should check for a Robots Noindex meta tag on the page. If the source code looks strange you may have to use the Chrome Inspect tool to see the fully rendered page.

2. If there are no blocking robots meta tags on the page you should check the HTTP response for an X-Robots header.

3. If there is no X-Robots header, it's probably because of the duplicate content and spammy(seeming) subdomain setup.

Sorry about the wait. If you include the site URL it will get other community member's curious enough to check it out next time.

I hope this helps. If not, feel free to message me.

If you can share the site I'll look to see if there is markup on the page that is causing this so you can identify what to remove.

If the user experience for paid traffic is bad, you'll be losing money. I think this area is mostly self policing. I have seen zero evidence ever that Google takes paid social traffic user experience or volume into account for organic rankings. It doesn't make sense to do that because those users behave drastically different than a user on organic search. Why would you base organic search rankings on paid social traffic?

Hello Micey123,

That sounds good except you should put the sitemap reference for xyz.abcd.com within that subdomain's robots.txt file as well: xyz.abcd.com/robots.txt, as each subdomain should have its own robots.txt file.

Ideally yes, you would have a separate XML Sitemap file and Google Search Console profile, as well as a separate (and combined) Google Analytics view for each of the thousands of subdomains.

If that is not possible, at the very least you should have a sitemap that includes every indexable page on the primary site, as well as an XML sitemap on each subdomain, which is linked to in that subdomain's own Robots.txt file.

According to the XML sitemaps protocol, XML sitemap files can not contain URLs from different domains. This includes subdomains. You have to keep all URLs to a single domain per XML sitemap. See sitemaps explained for more info.

As for the Title Tag thing, I don't see why you couldn't have a street name AND city -- or neighborhood and city -- so that they would all be unique, while still including the city.

Something could have been "created" 100 years ago, but only "Published" for the first time last month. I think datePublished is what you should use for articles, blog posts, etc... dateModified is also important for when you update the page to show it's fresh and needs to be re crawled and rendered.

I wouldn't show any of them on the front end, though some people do prefer to see the Date Last Modified or Original Publish Date somewhere so they know if it's still relevant. It depends on the type of content you're publishing and if the topic moves quickly.

If you want to provide the markup to search engines without showing it on the front end use JSON-LD.

I like Logan's answer.

You may, however, consider allowing a single "endlessly scrolling" Reviews page for each product, which:

1. Would NOT have the first X reviews shown on the Product page (sorted in whatever way works best for you).

2. Would perform the role of Review Pagination, though without taking anyone off the product page unless they REALLY wanted to see more reviews by clicking the (see all reviews) link. I think this is pretty similar to how Amazon does it, and they know what they're doing when it comes to maximizing conversions.

3. Would be indexable and optimized for "Product Name Reviews".

4. Would never be "built" unless there are at least X-reviews for the product, necessitating pagination.

Unless you're specifically calling out Bing or Baidu... in your Robots.txt file they should follow the same directives as Google so testing with Google's Robots.txt file tester should suffice for all of them.

Your question is "What we doing wrong"? Could you be more specific? I see at least 44 pages indexed. Can you provide a few examples of URLs that you think "should" be indexed but aren't? Or is your problem not about how many pages you have indexed?

I don't know of any further updates about Fred other than what is here:

https://moz.com/google-algorithm-change

However, over the last week (Mid May) there has been a lot of noise and fluctuation according to many sources.

Let us know if there is anything we can learn by what you find out. Happy to discuss further if you share some details, but it would not be uncommon for Google to decide to push thin eCommerce pages down.

A jump in 404 errors in and of itself isn't harmful to the site. I'd say as long as they don't KEEP trying to access those URLs you should be OK. Keep an eye out for "soft 404s" as well. And you could also change the status code to a 410, which means the page is permanently GONE, as opposed to just "not found" at the moment.

Here's a flowchart that I hope will help:

http://cdn2.hubspot.net/hubfs/444100/Out_Of_Stock_SEO_/Out_Of_Stock_Product_Flowchart.pdf

I think it really depends on how it's done. You certainly don't just want a whole page of comments with no blog post above them to be indexed on Google, as the experience of landing on that page from search engine results would be poor.

You have 50 legitimately useful comments on the post? I find that about 75% of our comments are either outright spam, or poorly veiled attempts at it. You may be able to delete any that are constructive to the conversation.

If you paginate the comments to keep some of them off the post in order to speed it up, I'd recommend setting the Robots meta tag on the comment pagination pages to Noindex,Follow.