Welcome to the Q&A Forum

Hi CJ,

I can't imagine a situation where I'd want to do this, but I'm sure you've done the analysis to determine that it's better for your UX. Just make sure you consider this:

Not sure what you're using to make the nav dynamic, but you should make sure Google sees it the way you intend. You can use the Fetch and Render in Search Console. You can also use the first part of this inforgraphic to set up a browser to view your site in a live environment the way search engines see your site.

You'll want to make sure that once you've disabled CSS and JS that your navigation is still visible. A lot of authority/juice/whateveryouwantocallit is passed through your nav. Having your nav visible this way also ensures quicker crawling/indexing of new content on your site.

No worries, that's what this community is here for!

Google views subdomains as different entities. They have different authority metrics and therefore different ranking power. Removing a URL on a subdomain won't have any affect on it's brother over on a different subdomain (for example: dev. and www.).

Good call to keep the disallow: / on the dev.chiplab.com/robots.txt file - I forgot to mention that you should leave it there, for anti-crawling purpose.

This is the query you'll want to keep an eye on. The info: operator is new and can be used to show you what Google has indexed as your 'canonical' homepage.

You should be all set# I wouldn't worry about link equity, but it certainly wouldn't hurt to keep an eye on your domain authority over the next few days.

Hi Chase,

Removing the subdomain within Search Console (WMT) will not remove the rest of your WWW URLs. Since you have different properties in Search Console for each, they are treated separately. That removal is only temporary though.

The most sure-fire way to ensure you don't get dev. URLs indexed is to put a NOINDEX tag on that entire subdomain. NOFOLLOW simply means that links on whatever page that tag is on won't be followed by bots.

Remember, crawling and indexing are different things. For example, if on your live www. site you had an absolute link somewhere in the mix that had dev.chiplab.com in it, since you presumably haven't nofollowed your live site, a bot will still access that page. The same situation goes for a robots.txt disallow. That only prevents crawling, not indexing. In theory, a bot can get to a disallowed URL and still index it. See this query for an example.

Glad to help!

Hi,

Moz is reporting these as duplicates because more than 90% of the source code is a match. The body content doesn't have enough differentiation to qualify them as unique pages.

Even if you could, you don't want to tell Moz to ignore things like this, because these types of duplications (or near dupes) are exactly why you're paying for Moz Being notified of issues like this gives you items to take action on and improve your overall site visibility.

Hi,

You should also setup properties for all versions of your domain. Since you've got an SSL, claim non-www and www for both secure and non-secure:

• https://villacollective.com
• https://www.villacollective.com
• http://villacollective.com
• http://www.villacollective.com

You can set your preferred (https://www) domain in the settings. Having all of these properties established will allow you to identify any problems you might have with indexing of different URL types, or if something weird is going on with any of them other than your preferred.

This is exactly the solution I've been after. Your input and walk-thru is much appreciated!

Hi,

Cyrus Shepard did a really good post on this not too long ago. There's a lot more to it than simply redirecting the old URLs. Check out the full list here: https://moz.com/blog/seo-tips-https-ssl

Post-launch, you'll want to closely monitor the index. Check back daily (it only takes a few minutes) to ensure that your HTTP URL count is decreasing and your HTTPS count is increasing.

It's not a matter of keeping them happy, it's simply helping our client accomplish what is best for their SEO during this migration. We have a really good relationship with them, so it's in everyone's best interest if we help find a viable solution.

Unfortunately, launching all at once isn't an option. This migration has been planned for months, there's no going back to the drawing board at this point. There won't be any brand confusion because visitors don't have much reason to be bouncing around to the different sections, they're very localized.

Thank you for your input, but it looks like I'm still on the hunt for a solution.

Thanks for your response Ruth.

Luckily, the URLs won't be changing....at least that's the plan anyway!

I'm looking more for info on how to have one domain with different sections spread across 2 different servers. The new development company has a proprietary CMS and are redesigning portions of the site incrementally. They will probably be reluctant to work off of the old development company's server, which is why we're trying to provide a solution that makes both dev companies happy.

Thanks for your response!

The new dev company proposed the subdomain idea, which I'm adamantly against. So this is why I'm on the search for an alternative- surely, someone else has had a similar situation.

There is a proprietary CMS involved, I should have mentioned that initially, which is where the real challenge comes in. I don't think either of the developers would be thrilled about a recommendation where they put there info on someone else's box, unless there is some way to lock down access that I'm not familiar with.

Hi Mozzers!

I've got a client that is in the early stages of moving the development of their site to another company and therefore, a new server. The site is very large and the migration will take place over 18 months. In the beginning, smaller chunks of the site will be moved, and as that process gets dialed in, larger portions will migrate.

It was brought to our attention today that they (on either side of development) have not yet worked out the logistics of keeping the domain and URL structure consistent throughout the migration. The initial proposal was that they publish newly migrated pages to a subdomain, which we obviously want to steer away from. I'm now on a mission to find a solution that will make everyone happy; client, old dev, new dev, and us (as the SEO partner).

Does anyone have experience in managing SEO through a migration such as this?

I'd really like a more robust XML sitemap tool with the following features:

1. XML Sitemap_Index_ generator - building these manually is no fun
2. Recurring XML sitemap tool

• Automatically generates a new sitemap based on a specified cadence, exports to specified folder
• Includes parameter to eliminate URLs based on canonical value, status code, URL type, robots disallows, et al.

I realize most CMSs have the ability to auto-update the XML, but it's usually pretty junky and doesn't allow for any exclusions or parameter-driven specifications.

You're off to a great start. Also be sure to check out Moz's new Keyword Explorer: https://moz.com/explorer. This will be really helpful in expanding your keyword list to be inclusive of more variations and other related topics to cover.

As Yossi said, configuring parameters in Search Console should help - _but, _that's only going to help you out in Google.

Adding a disallow for those parameters in the robots file will help solve the problem in other search engines.

The thin content is definitely contributing as well. Moz identifies dupes based on a source code match between any two pages of 90% or higher. When you consider all your template code is the same across every page, thin content isn't enough to differentiate the source code.

I also noticed on one of those screenshots that you got a one dupe of /shop/necklaces/ and /shop/necklaces/necklace/. If you can, I recommend removing that second one with doubled up 'necklace' folders, that's going to cause a lot of dupes as well.

Hi Jacob,

I took a look at your site, and the canonicals appear to be configured correctly. When you look at your duplicates in the Site Crawl report in Moz, and you click the + next to where it says "1 duplicate", what are you seeing? Is it a URL set like the example you've used above, or something else?

This type of duplicate applies to far more than just the homepage...so by implementing a single redirect rule, you handle this type of duplicate for every single URL on your site, and neither people nor search engines will ever see the undesired version.

If you do this via canonical tags, you have to include the canonical tag on every page, which could be very time consuming depending on how large your site is.

Hi,

Ideally, you would handle www and nonwww duplication by way of a redirect rule. Both versions of that URL should not render, i.e. when you go to www.example.com it should take you straight over to example.com.

You can handle this with canonical tags the way you've proposed, the URL in the href element should be the one you prefer. However, this should be reserved only as a work-around in the event that you can't get implement a server-side redirect rule to handle ALL www-to-nonwww issues.

That's the only method I know of deter unqualified clicks, interested to see if anyone else chimes in with some useful nuggets of info on this topic!