Here's my $0.02:

I think that these two companies probably made decisions, but not completely based on SEO or organic ranking.

The Mic.com site that is using sub-directories will likely see much better SEO, because all of the content is on the same domain, and not treated differently.

My assumption for the Vice.com site is that they want to have different channels or content on other subdomains.

My hunch is that for Vice.com, they decided to go with subdomains, so that they could have this content live on different physical servers or different infrastructure.

I took a look at the main site, www.Vice.com, and it's using Tumblr, running on AWS with Elastic Load Balancing.

For the Munchies.vice.com, it's running on WordPress.

While it is possible to have content displayed from WordPress on one subdirectory and Magento on another (by either installing both applications on the same server, or creating virtual links behind the scenes) a lot of companies will opt to do this on separate systems.

That's probably the reason that they went this way.

In the end, SEO doesn't trump everything...

But, here's a reference about sub-domains vs. subdirectories on Moz:

In the past, I've answered a similar question in the past here: http://moz.com/community/q/blog-on-subdomain

But the gist of it is:

store.mydomain.com --> content on the store. is treated as a different site, and SEO efforts (content, inbound links, social media) only help the subdomain.

mydomain.com/store --> subdirectories are usually the way to go.  All of the content, inbound links and social media shares will help build the overall domain authority for you.

My recommendation is to go with the sub directory (mydomain.com/store/, and there are a whole lot of articles that back this up:

http://moz.com/community/q/blog-on-subdomain-vs-subdirectory-best-practices

http://www.mattcutts.com/blog/subdomains-and-subdirectories/

http://moz.com/community/q/best-place-for-a-blog-blog-mydomain-com-or-mydomain-com-blog

Hope this helps,

• Jeff

Yes, the two pages look almost identical, with the exception that one page has a lot more content that's bolded.

My $0.02 is that you'll likely get in trouble for duplicate content with both pages.  I'd recommend this one:

http://www.yourpharmacy.co.nz/beauty/clarins-skincare/clarins-advanced-extra-firming-eye-contour-cream-20ml

… as this URL has "beauty" and "Skincare" in the URL.  That said, it's a little bit long, so I might recommend taking out one of the clarins in the URL.

Then, I'd use the rel=canonical tag for the other page to make this one above the primary page.

It does appear that Adobe Catalyst Sites don't support the rel=canonical tag fully, so you might have to manually take care of this, as described here: http://forums.adobe.com/message/5948735

Hope this helps!

• Jeff

Ricardo -

While Google usually doesn't have a problem indexing sites with shared IPs, I'd highly recommend each site have it's own IP address.

While it's fine if you're hosting multiple sites on a VPS that share an IP address, long term, you need to worry about things like email blacklisting (if one site starts send out spam) or other issues, too.

I don't think that you'll see any negative implications for rankings if you change the IP address; I'd perhaps set the TTLs in your DNS zone file for the domain down as low as it can go (i.e. 3600 seconds or 1,800 seconds) to prevent users from not seeing the site if they have the older IP address cached on their computer.

Hope this helps...

• Jeff

Sheena -

Two out of three isn't bad

Without seeing the actual sites, my best guess is that the www.product.com is an strong domain name with exact match keywords. And when it was moved over to the brandname.com/product the new location didn't work as well as in the past.

301 Redirects transfer about 85% of the link value, according to the Moz blog article here:
http://moz.com/blog/save-your-website-with-redirects

"When done properly, we know from testing and statements from Google that a 301 redirect passes somewhere around 85% of its original link equity."

According to an interview with Google's Matt Cutts: http://www.seroundtable.com/archives/021832.html

"Eric Enge: Let’s say you move from one domain to another and you write yourself a nice little statement that basically instructs the search engine and, any user agent on how to remap from one domain to the other. In a scenario like this, is there some loss in PageRank that can take place simply because the user who originally implemented a link to the site didn't link to it on the new domain?"

_ "Matt Cutts: That's a good question, and I am not 100 percent sure about the answer. I can certainly see how there could be some loss of PageRank. I am not 100 percent sure whether the crawling and indexing team has implemented that sort of natural PageRank decay, so I will have to go and check on that specific case. (Note: in a follow on email, Matt confirmed that this is in fact the case. There is some loss of PR through a 301)."_

Perhaps the other two that are performing well are in a less competitive space; this one might be more competitive from other established players in the industry.

For the other two sites, taking a 15% hit probably didn't make a difference, but for the one site, it's likely that it did.

Hope this helps!
-- Jeff

Yes, unfortunately if you change the address that you have listed on your Website, along with the address you have for a Google+ page, then you might start to have issues with local search results migrating to Sufolk instead of London.

My recommendation: Change your Google+ listing to a Service-area business

For local business search, you'll want to set up the business so it not based on the physical location / address (i.e. your new home in Sufolk), but serves a greater area (i.e. London). In order to do this, you will need to set up your Google+ account as a Service-area business on Google.

This is perfect for a trainer, local plumber, tree trimmer or construction crew that works at customer's locations (either homes or businesses) vs. your home address.

My recommendation would be to go here:
https://support.google.com/business/answer/3038163?hl=en

... and set up your service areas based on the zip codes or cities that the business serves.

You also have the option to check or uncheck, "I serve customers at my business address."

You might need to go through another round of verification to make this change, however.

I hope this helps!

Thanks,

• Jeff

Here's my quick thoughts on this:

http:

Pro:

• Quick, fast and easy
• No SSL fees
• Super fast
• Most content pages don't really need to be encrypted

Cons:

• Anyone snooping on your connection at a coffee shop can see what you're seeing.
• NSA can read what you're doing

https:

Pro:

• Nobody will be able to see that you're reading a blog post about how to cure your herpes.
• Google was pissed off at the NSA, and is now using sites that have SSL as a ranking signal (but it's not a silver bullet). Here's an article I wrote about that: http://www.customerparadigm.com/google-boosting-ssl-encrypted-sites-in-their-search-results/
• Done right, it's nearly as fast as non-secure pages

Cons:

• It's expensive to buy an SSL certificate (although there may be a non-profit starting next year that will give them away for free)
• It's a pain to generate keys, install intermediate certificates.
• It sucks when your SSL certificate expires on your site, even if you're not using it anymore (Google will show a big error to many users: http://www.customerparadigm.com/how-an-expired-ssl-certificate-can-drive-traffic-away-even-if-youre-not-using-it/)
• It can be slower, because of the math required to encrypt and decrypt information.
• You have to be better at coding sites, because if you have things like non-secure images, css or other resources on your secure page, it will throw an error.

Hope that helps...
-- Jeff

I agree with Peter. If your site is brand-new, it's not going to rank all that well in Google or other search engines if nobody else is pointing to it. External links pointing into a site, combined with the relevancy of the content on the site, was how Google dominated the search industry 15 years ago. A way to visualize this is to take a look at this photo that I took about a month ago. Based on this photo... who do you think is the most important star of the evening? In this shot, all of the other kids have their fingers pointing to the "one" most popular girl in the middle. Inbound links (from relevant, authoritative sites) work the same way and help indicate relevance. Hope this helps! -- Jeff

popular-girl-link-example.jpg

Samuele-

Sorry to hear that the server was down for five days.  That's not a lot of fun to deal with.

Here's a great link to an interview by Matt Cutts about Website downtime and how it affects Google rankings:

http://searchenginewatch.com/article/2281151/Matt-Cutts-Short-Website-Downtime-Wont-Hurt-Your-Search-Rankings

Basically, if the server is down for a day, you're fine.  More downtime than that, though, and Google sees this as a signal that the user experience might not be amazing.

My recommendations to prevent this from happening again:

1. Back up each site to at least two locations.  In the case that a server like this goes down, you can migrate the sites to a different host quickly.  Make sure you have the database + the site contents backed up.  I recommend backing up locally to a hard drive, as well as another cloud-based site, too.  For a critical site, it may be worth having a "hot" backup site that can be pushed live via DNS quickly and easily.  For a site with 100+ sites on it, make sure you have a list of all of the sites on the server, and order them in importance of what is most critical to work on first.

2. Make sure that the DNS doesn't route through the server with 100+ sites on it.  Use the DNS controls at your domain name registrar, instead.  That way you can quickly re-route the DNS to go to a new hosting platform, and not have to wait for the server to come back up.

3. Consider moving to a different hosting platform that has more uptime / reliability.  100+ sites on a server is a lot of eggs in a basket.  (Note: I've done something similar in the past, and it's not worth it to have all of those sites sitting together on a shared server.  Better to break them up and put them on several different servers if possible.)

Finally, once the site is back up, I'd try to bolster the importance of the site with additional relevant content, inbound links, social media, etc.  I might suggest a permission-based email campaign to past customers to bring them back, and let them know about the site outage.

Hope this helps...

-- Jeff

I think that the most important thing is to test.  Everything that you can.  And realize that when you go live, some things aren't going to work, and that is part of the process.  And have people on hand to fix things quickly.

For this reason, don't plan on going live on 5:00 pm on a Friday evening, when everyone is going to be out of the office and unreachable for the weekend.  Try Monday morning, when you can have everyone on hand.

Before you go live, though, these are a few things you should do:

1. Set the TTL (Time to Live) for your DNS A record for the site to as low as possible (i.e. 300 seconds).  This will prevent the DNS from being cached when you finally push it live.

2. Map all of the existing pages, and make sure that you have 301 redirects in place for everything.  Make sure that they only have 1-2 redirects if possible.

3. Make sure that your SSL is going to transfer properly.

4. Make sure that you have all of the key login information for your payment systems, and any other integration parts you might have.

5. Try to pause the PPC advertising during the transistion, to make sure everything is as smooth as possible.

6. I recommend keeping all of the images from the old site still live on the new site, in case they are still used for email campaigns or referenced elsewhere on the site.

7. Test all of the forms to make sure they work well.

I also like Search Engine Watch's 25 things to test before your site goes live:
http://searchenginewatch.com/article/2287002/Website-Launch-Checklist-25-Things-to-Test-Before-Your-Site-Goes-Live

Hope this helps!
-- Jeff

Josh -

The rel=canonical tag should be used for pages that have virtually identical content.

For example, if your page is:
http://www.domain.com/articles.html

... but the page also loads with:
httt://domain.com/articles.html

Then you'd want to put a rel="canonical" link in the section of the HTML page:

Here's Google's page on the rel canonical tag:
https://support.google.com/webmasters/answer/139394?hl=en

What it sounds like you have going are multiple pages (Pagination) that list articles, and you should use the rel=prev/next to not have duplicate page content issues.

The recommendation from Moz:
http://moz.com/blog/rel-confused-answers-to-your-rel-canonical-questions
...  is to:
Either rel=canonical to a "View All" page (if having all results on one page is viable) or that you use rel=prev/next tag, as described here: http://googlewebmastercentral.blogspot.com/2011/09/pagination-with-relnext-and-relprev.html

Hope this helps!

• Jeff

Screen%2Bshot%2B2011-09-15%2Bat%2B12.48.10%2BAM.jpeg

Carl -

I think the links on the bottom of the page are pushing it a little bit. With the top navigation, all of the other content, the links at the bottom of the page might be ignored.

My biggest issue is that the shield stays fixed at the top, but when I scroll down on an interior page, the text goes behind it. If only part of a link is behind the shield, the entire link is not clickable. At least not on a Mac / Safari, which is what some of the cool dress shopping users will be using (IMHO, not the best user experience.)

The blog posts don't appear to be like links, so many end users might not actually click on them, too. (Underlined or something might help.) I'm also not a huge fan of the "read 5419 times" … as it strikes me like the old-school hit counter. Perhaps it's just distracting me away from the topics, though.

When I do drill down, the page doesn't appear all that engaging. For example, on a post like this: How to Measure Fabric Length for a Pair of Pants
(http://www.ditalia.com.au/component/k2/article/how-to-measure-fabric-length-for-a-pair-of-pants)

There's not a ton of content, and it's a bit hard to read. This page might benefit from a diagram or drawing, as well as line breaks.

Sorry if my feedback is leaning more negative on the layout… it seems busy to me. If your target audience are brides-to-be who want wedding dresses and information, I'd try for a user experience that calms them. To me, the links at the bottom of the page have the opportunity to overwhelm them…
Hope this helps,
-- Jeff

My $0.02 is that javascript might work for your site, but it's not going to give you the benefits that 301 redirects will offer to you.

According to Google's Official Webmaster Central Blog, as of May 23, 2014, Google is able to execute Javascript:
http://googlewebmastercentral.blogspot.ca/2014/05/understanding-web-pages-better.html

That said, if you have your javascript or CSS in separate files, and are blocked with robots.txt, according to Google, they won't be able to execute it. And according to the post, they can't process all javascript.

It's not a bad thing to have 404 pages for pages that you want to kill off and let die. If you do have important inbound links, though, it's better to 301 redirect them and keep 85% of the link strength. More backup on this:

According to Rand Fishkin's Moz blog writeup, Are 404 Pages Always Bad for SEO?
http://moz.com/blog/are-404-pages-always-bad-for-seo

"When faced with 404s, my thinking is that unless the page:

A) Receives important links to it from external sources (Google Webmaster Tools is great for this)
B) Is receiving a substantive quantity of visitor traffic
and/or C) Has an obvious URL that visitors/links intended to reach

It's OK to let it 404."

According to Moz's Redirection SEO Best Practice:
http://moz.com/learn/seo/redirection
... you want to use a 301 redirect to indicate that the content has moved permanently.

I hope this helps!

-- Jeff

Meghan -

This is a pretty common occurrence with companies that have locations in different areas... especially if the ownership is slightly different.

What I would do is add as much unique content to each site, including:

• Photographs of each location, inside, outside, merchandise.
• Directions to the location from different areas.  For example, for the Colorado location, give driving directions from DIA (airport), downtown Denver, Boulder, Grand Junction and Colorado Springs.
• Customer testimonials that are unique to each location.
• Local resources in each area.  For example, if the location sells picture frames, put together a list of photographers in the area who are able to create amazing, award-winning images to fill those frames.  Get images from those photographers to add to the site, and testimonials, etc.  Another example might be if the location is a hotel or motel... you could list the "must see" attractions, restaurants around the business.
• Try to make sure your page names are different.  Instead of /about-us/ or /about.html for the "About page" name this page /about-Denver-Colorado-businessname/ and /about-Indiana-Business-Name/ to keep page names as different as possible.
• Use a slightly different methodology for Title and Description tags as well.
• If possible, use different image names, sizes and alt-tag description for the images in the navigation and throughout the two different sites.
• Consider using RDFa microtagging to keep the sites Name, Address, Phone # information (NAP) separate and distinct.
• Consider using different Facebook, LinkedIn, Twitter, Pinterst pages to keep things separate.
• Consider using different hosting providers to keep the C-blocks as separate as you can.  You could try hosting one site in Indiana and one in Colorado, or just use two different hosting companies.

Hope this helps!
-- Jeff

Bryan -

The best practice is to 301 those pages to a relevant top-level category page, so that Google doesn't see that links into the site from social media or other pages is broken.

You can simply let them be a 404, but that doesn't send the solid signal to Google that you're managing the pages on your site well.

Yes, once the pages are removed, I'd recommend re-generating the XML-based sitemap and resubmitting it to Google, so they don't look for those pages.

But 301s for those removed pages will eliminate any future issues with people who bookmark a page or link to it from another site.

Just my $0.02...

Laura -

If you need to find a list of all of the older links, try to see if you can find a cached version of the older site's sitemap.  From there, you can extract all of the original links and run a check...

I did a quick search on the Way Back Machine (see screenshot) and found the June 27, 2013 version of the site.  It doesn't appear that the site has a sitemap, but you could probably use the HTML in the page to check and see if links are redirecting properly, too.

Thanks,
-- Jeff

electric-heating-supplies-wayback-machine-june-27-2013.jpg

Clifford-

Industry.com looks to me like a directory site where you are encouraged to pay for advertising.

On many pages, it appears that a link like "Label Printer" is just displaying Google Adsense, and trying to get people to click on ads.  (See screenshot.)

My $0.02 is that the industry.com site appears to me to be a directory, and the kind that Google is trying to penalize people for using for links.  I would avoid this, as it probably won't do a lot to help, and could wind up hurting the site with spammy looking links.

That said, Industry.com has a 39 domain authority, and 162 linking root domains coming into the site.

industry.com-screenshot-label-printer.jpg

Gina -

I've attached a few screenshots showing how the site displays in different widths.  The site performs pretty well in the different widths, as you can see.  The portfolio page works well, as does the contact information page.

I'd recommend putting in a footer navigation, as a mobile user who is on the bottom of the page might want to navigate that way instead of trying to scroll back up the top of the page.

The menu seems to work well at the tablet size and the smart phone size as well.

Personally, I think that the new responsive site layout is much better than the existing site.  The live site has huge, dense blocks of text that make my eyes gloss over, overwhelmed by the volume of content.

Hope this helps!

-- Jeff

fat-eyes-desktop-version.jpg fat-eyes-tablet-version.jpg fat-eyes-iPhone-Version.jpg fat-eyes-phone-layout-menu.jpg

Bob -

I'm assuming that your blog promotes the custom design and printing business in the UK?

If that's the case, I'd recommend putting up articles that are potentially interesting to end users, including:

• Perhaps commenting on how direct mail pieces done by a big company (i.e. Orange) were created, and why they have been successful.  For example, it might be the images, calls to action or compelling content.
• Writing about the choices in paper, and how different types of paper can connect differently with a print campaign.
• Focus on a customer's success - how direct printing allowed them to expand and gain new customers, or convert older ones instead.
• Perhaps write about database marketing, and how RFM can work (recency, frequency, monetary value) to determine who to send information out to.

Post a link to the blog so we can take a look...

Bryan -

I just did a quick look at your site. You have a crazy amount of Google +1s.

Anyway, Google seems to have about 5,260 pages indexed, according to a quick search (see screenshot).

Google is most interested these days in creating an amazing user experience.  I wouldn't worry about 100 pages, as a 301 is going to be a better quality signal to Google than 100 sudden 404 errors showing up on the page.

If you're really worried, though, and want to reduce the number, you could do a backlink check on the pages you're about to remove and see if anyone has linked in to those pages directly.  301 those, and then perhaps don't worry about the others?

macdecals-pages-indexed-by-google.jpg

Saijo-

Ideally, a sitemap has a list of all of the pages on a site in a flattened out structure, so that a search engine is able to view all of the pages quickly and easily.

Typically an eCommerce site will have a structure like this:

• Home Page
• About Page
• Other content pages
• Main Category Page (with pagination), lists sub-categories
     - Sub Category Page (with pagination), lists products (or perhaps another sub-category).
• Individual Product Pages

Best practice seems to be:

• Make sure that all of the content and individual pages on the site are on the sitemap.
• For any page with pagination, link to the "View All" version of the category page (or any page with pagination), where instead of listing 9, 25 or 50 items, it lists all of the information on the page.  That way you don't have to list the paginated pages in the sitemap.
  (Note: if you have thousands of items on one of these "view all" pages, this might not be a viable option because the page load time might be too long and/or contain too many links).

Hope this helps...

• Jeff

Rachel -

Our company is a Magento Silver Solutions partner, and we have many Magento Certified Developers on our team.

Magento can be a powerhouse of an eCommerce system (that's probably why it has a 26% marketshare in the Alex 1 million sites that are eCommerce).

But it does require a lot of memory to run properly, and the hosting does need to be fine-tuned.

It does look like you are using a CDN for your site, and in a speed test, the site is loading quickly in 1.98 seconds (see screenshot).

I'd be happy to run our Magento Code Audit tool on the site, if you want to contact me directly:  jeff -at- customerparadigm .com, and it will let you know core file modifications, extensions that are running, and server specs.  We normally charge for this, but because it's the holidays, I'm happy to do this at no charge

speedtest-test.plasticplace.com.jpg

That makes sense... I didn't realize you were talking about top level categories; I thought it was more of a product page...

Post and let everyone know how it turns out...

Jorg -

I do agree with Peter; you should absolutely use 301 redirects to redirect your old page names to the new ones.

I would try to keep some consistency for your URLs, if you could.

So if the page now is www.domain.com/about.html --> go with www.domain.com/about/

This will (a) make the 301 rewrites a lot easier to do, and (b) keep things a bit more simple for you.

That said, there are ways to keep the old page name extensions intact, but it depends on your server settings and how much access you have to modify things.

For example, you could have a page that appears to be:  about.html  ... and ends with the .html extension, but was really a php page.

Depending on the server, this is usually a quick thing to fix, although you'll need to update your content management system to work with this.

I'm a big fan of not changing the URLs if you don't need to.  You'll still do okay if you do a single 301 redirect, but more than a few hops and you'll start to loose value.

Hope this helps!
-- Jeff

Parallax design is a hot design topic, but I haven't seen any real A-B split test that shows a real difference.

In general, I'm not a huge fan of the one-page, scrolling website. I think that it's okay for a small business site with not much to say. But it severely limits building deep content pages... the sort of 12,000 word pages I love to write that delve into a topic and set you apart as an authoritative expert in the field.

Search Engine Land does have this great article about the perils of Parallax design for SEO:
http://searchengineland.com/the-perils-of-parallax-design-for-seo-164919

Key takeaway: The one-page, long scrolling website that so many design agencies love to use doesn't really give you more than one page of content for your whole site.

This is a good article about Parallax design, and how it impacts the end user experience.
http://uxmag.com/articles/the-hypnotic-effect-of-parallax-scrolling-and-how-it-impacts-user-experience

Key takeaways:

• Parallax can be hypnotic and engaging (but there's no real data behind this)
• Page load times can increase (bad for SEO) because you have one really long page.

A student at Purdue wrote a thesis about it, and says it's "more fun" for the end user, but that's about it.
http://docs.lib.purdue.edu/cgttheses/27/

Hope this helps!
-- Jeff

Wesley - I do agree with Federico.

That said, if they really don't want those pages indexed, use the belt-and-suspender method (if you wear both a belt and suspenders, chances are greater that your pants won't fall down).

I'd put a robot.txt file to disallow the indexing of the directory, and also no-index / no-follow each of the pages, too.

That way when they have someone working on the pages in the site and they change things to followed, you're still covered.  Likewise, if someone blows away the robot.txt file.

Just my $0.02, but hope it helps…
-- Jeff

I agree with Federico.  If you don't do 301 redirects for the older pages --> mapped to the new pages, the site's rankings will likely drop like a stone.  Especially if you have inbound links pointing to those older pages.  Google will figure out from the new site structure what pages should be indexed.  But best practice is to map the older pages to the new ones.

Depending on the site, you should be able to automate some of this, and plug it into an excel spreadsheet to come up with the 301 redirects for the .htaccess file.

If for example, the older URLs are all like:  http://www.domain.com/about-us.html and the new site is http://www.domain.com/about-us/  then it's easy to create this rule and apply it more systematically (using a programmatic rule in the .htaccess file), or just plug all of the pages into a spreadsheet and have this apply:

Redirect 301 about-us.html http://www.domain.com/about-us/

You are now much later in the game, but when we are working on a new site layout that changes the URL structure, we will often map this out (page by page) early on, so that we don't miss any of the older pages on the site.  And in some cases, we've made a lot of effort to keep the existing site structure, as older pages that have ranked well for 10+ years might be better left alone, without a name change.

That's my $0.02, though…  I think that 301 redirects are often overlooked in the website design budget, but if you want to make sure that your client is happy 3-4 weeks from now and refers more business to you, this is a must-do item, in my professional opinion.  That said, it's not fun to go over budget on a project

Ruben -

I think it's a wise move to have Google and other search engines index your privacy policy.  I'd recommend putting it in the footer of the site.  This is a standard part of nearly every website, so I wouldn't worry about including it.

Not including it, though, might raise flags and decrease the amount of trust a search engine places in your Website.

From a consumer perspective, many, many studies in the past have show a direct correlation between having a privacy policy on a site (or simply a link to a privacy policy) next to a form, and increased conversion rates.

My worry if you disable the ability of a search engine to index your privacy policy is that it may hinder this "trusted" mark by a search engine, as it may appear that you are trying to hide.

If you do plan to engage in a lot of deceptive practices, though, it might be nice to not have these pages cached, so nobody can look back at your older privacy policy (i.e. through the Way Back Machine).

One cynical thing to note: whatever you say on your privacy policy (i.e. we will never, ever sell your information), you should abide by what you say.  Otherwise, the FTC will come down on you for deceptive practices.  That's why most privacy policies are written by lawyers and allow the company to pretty much do whatever they want with the end user's data.  And why nobody usually reads them.

Hope this helps!

-- Jeff

That's going to be more of a hosting question than anything else.

If your website's hosting will allow you to recognize the .org, .info and .net domains, you can have them show up.

However, what you want to be careful of is that you're not serving pages with www.mydomain.info/about/ that is the same duplicate content that is on the www.mydomain.com/about/ page.

My recommendation would be to go up a level to your domain registrar, and simply have these sites forward (not URL mask), but forward to the main one.

So if someone types in www.mydomain.net, the system will automatically redirect to the proper domain.  This is what we have done for the www.CustomerParadigm.org domain --> it just goes to the www.CustomerParadigm.com as a domain forward.

Godaddy has an easy way of doing this; other registrars make it more difficult.

You can also handle this on the site with 301 redirects for the other domains, but again, this is going to be something to work on with your web hosting platform.

Hope this helps!
-- Jeff

Honestly, I don't the the gradual migration to the new site is a very good idea.  If you take the route you've outlined, you're likely going to drop in the rankings due to duplicate content issues, or just the fact that you are no-indexing content.  Once you no-index content, it can sometimes take quite a while for the content to be re-indexed after you remove the no-index restriction.

I'd instead recommend putting up the new site in a development / test area.  If this is one a different subdomain, that's fine for now, but you should no-index / no-follow the test site.

Once everything is ready, flip the switch to have the DNS point to the new IP address for the new site, and then disable the existing site.  In order to decrease DNS caching issues, you may wish to set the TTL (time to live) for the A records down to 300 seconds or so.

As your URL stucture is changing, you will want to make sure that the URLS are all 301 redirected to their new location.  You can do this with a mod rewrite rule (if everything is changing from .aspx --> .php), or manually map out each page and put them in your .htaccess file.

I would test these out on a site like the http://httpstatus.io/ site to make sure it works properly.

And my recommendation is not to do the changeover on a Friday afternoon, unless you want to spend the whole weekend troubleshooting issues on the site.

Once the site is live, make sure things like the contact forms are working, and that any images on the old site are also moved over if possible (as you might be using them in email campaigns, etc.).

Hope this helps!

• Jeff

Unless it's a particularly amazing domain name, this is an issue that's going to follow you for quite some time.  The disavow link system can be helpful in circumstances like this, but it's always been promoted by Google as a tool of last resort.

Not knowing much about the site, my $0.02 would probably vote for a clean slate with a new domain name, and shut down the older site.

Jonathan -

Great question… There's a great Moz article from April 2012 about how to handle expired content.
http://moz.com/blog/how-should-you-handle-expired-content

In a nutshell, the author says that there isn't one solution for all situations.  But the lens that they give is to figure out what is going to create the best user experience.

The author's advice:
For the vast majority of scenarios, I'd suggest 301 redirecting your expired content to another page. This is usually the best option for SEO and can also be customized to enhance the user experience via dynamically-generated messages. For instance, if a product page had garnered external links, you're able to retain most of the link equity from those links via a 301 redirect (whereas with a 404, that link equity is lost). Why would you want to lose the link equity that you had worked so hard to obtain? Furthermore, it demonstrates to search engines that your site is well-maintained and up-to-date or "fresh".

However, for seasonal items, it's recommended that you leave the pages on the site year-round:

If a product is seasonal, such as the case for fashion products (example: swimsuits), you might want to leave the page on the site permanently… And if you don't want the page to be indexed in the off-season, add a meta tag to noindex/follow the page.

Hope this helps!

• Jeff

If you want to keep any SEO value from inbound links that go to any of those older pages, you'll want to 301 redirect them to a similar page (i.e. a top category page).

According to Rand Fishkin's Moz blog writeup, Are 404 Pages Always Bad for SEO?
http://moz.com/blog/are-404-pages-always-bad-for-seo

"When faced with 404s, my thinking is that unless the page:

A) Receives important links to it from external sources (Google Webmaster Tools is great for this)
B) Is receiving a substantive quantity of visitor traffic
and/or C) Has an obvious URL that visitors/links intended to reach

It's OK to let it 404."

According to Moz's Redirection SEO Best Practice:
http://moz.com/learn/seo/redirection
... you want to use a 301 redirect to indicate that the content has moved permanently.

Here's a post that describes how to create a more SEO friendly migration, here's a great info graphic:
http://moz.com/blog/achieving-an-seo-friendly-domain-migration-the-infographic

Hope this helps!
Thanks,
-- Jeff

Nick -

It's obviously not an ideal situation to have two different websites share the same business name, phone number and address.  But I think you'll probably be fine.

The thing that is top of mind for me is that you're not going to be able to have two different Google+ pages for the businesses - auto repair and auto sales, as they have the same name, phone number and address.  (At least without doing something like registering a DBA, or using a suite # or a different phone #).

I'd recommend adding as many images to the Google+ page as you can, and soliciting users for reviews.

One strategy I saw recently for auto repair places (via one of my photographer friends) was to print a 3x5 card with the business name, logo and ask people to review their experience on Google.

On the front side of the card, it reads:

Tell us About Your Visit Today
with Google Reviews

We value your opinion and want to make sure we make your experience the best possible.  Your feedback ensures that our team provides ou with the best in customer service.

(auto repair logo)

See reverse side for instructions on how to leave a review.

Other side of the card reads:

Google Review Process:
1. Go to www.Google.com
2. Search for [business name]
3. Click on Google Reviews (right of yellow stars)
4. Write a review
5. Sign in using your google account or click sign up for account in right corner.
6. Create Account.
7. Thank You!

Taysir-

Partial URLs are often formed when you have illegal characters in the URL (such as an & symbol or a space) or you have name-value pairs (?id=1&location=54).

In some cases, the URLs that are generated in a site map may not be URL encoded properly, and then you get an error when submitting the site map.

The reasons this can happen:

• You have a static page on your site with a space in the file name (i.e. /about us.html) You could fix this with a %20 where the space is (i.e. /about%20us.html)

• You have a content management system (i.e. WordPress) and the URL is based on the page name. Usually this can be fixed by changing the URL key and removing special characters and spaces.
  Here's a Google forum discussion on the topic:
  http://productforums.google.com/forum/#!topic/webmasters/oa0dbGvdP7c

• It's possible that you are using a relative URL in your CSS file, and that's throwing an error. More details here: http://stackoverflow.com/questions/940451/using-relative-url-in-css-file-what-location-is-it-relative-to

Hope this helps!
-- Jeff

Wojtek-

Here are a few responses to your question:

1. How do we host the website locally for each country, so local search engines recognize the website as a local website? Also, is it that important?

If you really want the sites to be considered "local" for each of their markets, it's best to have them hosted in their home countries. For example, .de should be hosted in Germany, .fr in France, etc.

That said, that can be logistically challenging, especially if you have a common backend system for maintaining content.

This is the best practice, but not always easy to maintain.

2. Is cloud hosting the right solution for this? We would have different server locations for each TLD/language. Surrounding countries would at least get a fast connection and download rate, if the server is located nearby.

3. If yes, can you recommend any companies doing cloud hosting?

Cloud hosting could be a good way to go, and should make management much easier

4. Is it also wise to additionally redirect the user to the local server based on his/her location?

I think it's a great option to recognize that people are in a specific country, and redirect them to the proper place. Or, give them a choice to see what they'd prefer. You might have ex-pats from the US that speak English, however, that want to interact with the English version of the site, so give them a way to interact.

That said, I'd do an A-B split test to find out and see what converts better.

5. Is there a risk of duplicate content or being recognized as a link spamming site (for having links to each other from different domains of the same site, the content will be in different languages, though) just by using this solution? We would, of course, keep the content separated by domain to avoid duplicate content.

As long as the content is in different languages, you won't have issues with duplicate content. I previously managed a site that was in English, French, German and Italian, and while it had identical products (including SKUs), the content on the site was tailored to each market and the sites ranked well in each local domain.

Hope this helps!

• Jeff

FYI, Google's Matt Cutts has broken from the previously stated mantra on the disavow tool, and now is encouraging Webmasters to use it if they are worried if a link is from a bad domain, due to poor SEO (or someone else trying to hurt your site by creating bad links):

http://searchenginewatch.com/article/2309486/Matt-Cutts-Use-the-Link-Disavow-Tool-Even-if-Your-Site-Hasnt-Been-Penalized

David -

My $0.02 is that you should keep the older page name structure, using the .html extension.

The reason? It looks like it's not too difficult to do, and then you won't have to worry about 301 redirects.

It's been well documented that 301 redirects only share about 85% of their value:

301 Redirects transfer about 85% of the link value, according to the Moz blog article here:
http://moz.com/blog/save-your-website-with-redirects

"When done properly, we know from testing and statements from Google that a 301 redirect passes somewhere around 85% of its original link equity."

According to an interview with Google's Matt Cutts: http://www.seroundtable.com/archives/021832.html

"Eric Enge: Let’s say you move from one domain to another and you write yourself a nice little statement that basically instructs the search engine and, any user agent on how to remap from one domain to the other. In a scenario like this, is there some loss in PageRank that can take place simply because the user who originally implemented a link to the site didn't link to it on the new domain?"

_ "Matt Cutts: That's a good question, and I am not 100 percent sure about the answer. I can certainly see how there could be some loss of PageRank. I am not 100 percent sure whether the crawling and indexing team has implemented that sort of natural PageRank decay, so I will have to go and check on that specific case. (Note: in a follow on email, Matt confirmed that this is in fact the case. There is some loss of PR through a 301)."_

If you are in a competitive space, I'd highly recommend keeping the older URL structure intact.

David -

It looks like there are two main options for you:

Keep the same URL structure (option 1), and create category pages that are state-based / area-based, that then have a short description of each location in that geographic area, with a link to their location page.

This is typically how it might be done with an eCommerce site, where you'd have a parent category (i.e. shoes) and then a sub-category (i.e. running shoes).

The downside to this is that you risk having duplicate content on these category pages.

Option #2 would be my recommendation, because you are including the area / state information into the URL.

One company that does not do this well is Noodles & Company.  Their location URL looks like this:

http://www.noodles.com/locations/150/

... where "150" is a store ID in a database.  Easy to pull out of a database table.  Less helpful to the end user who doesn't know that store ID 150 = the one closest to them.

It would be much better to have it listed like:
http://www.noodles.com/locations/Colorado/Boulder/2602-Baseline/

You don't want to go much beyond 4 layers, but it's a better way of indicating to Google and other search engines the location tree.

Also, I'd highly recommend using a rich-data format for displaying the location information.

For example, on the Customer Paradigm site, we use the RDFa system for tagging the location properly:

Customer Paradigm

5353 Manhattan Circle

Suite 103

Boulder CO, 80303

303.473.4400

... and then Google doesn't have to guess what the location's address and phone number actually are.

In my experience, the best way to do this would be to set up the .fr domain separately as it's own separate WordPress installation, and have it hosted at a hosting company with a presence in France.

However, what's best for SEO sometimes creates more work for administering a site, vs. having it all available from one login in one WordPress instance.

As far as using a .fr domain, there are many schools of thought on this.

This Moz blog goes into the top strategies:
http://moz.com/blog/international-seo-dropping-the-information-dust

Amazon uses ccTld (Country Code, Top Level Domains). For example, Amazon.com, Amazon.de, Amazon.fr, etc.

Apple uses a subdomain / sub-carpet strategy: (i.e. store.apple.com/es)

In my past experience building out eCommerce and other stores, if you host locally, and use different ccTld (i.e. domain.fr), you won't have to worry about the duplicate content issue, as Google and other search engines will see this as it's own site, especially if it's translated (well) into another language.

Here's more on International SEO best practices:
http://moz.com/learn/seo/international-seo

I hope this helps!
-- Jeff

There are two ways to handle load balancing, and it appears that your hosting company / server company chose to use the DNS round-robin routing option.

According to the Wikipedia page on load balancing:
http://en.wikipedia.org/wiki/Load_balancing_(computing)

"Load balancing usually involves dedicated software or hardware, such as a multilayer switch or a Domain Name System server process."

Round Robin DNS Load Balancing: Basically you use the DNS routing system to handle requests. When someone visits your site, 50% of the people are routed to www.domain.com, and 50% are routed to ww1.domain.com. Both sites contain the same identical content; it's the URLs that are slightly different. Sometimes the domains are the same; but you have different IP addresses for www.domain.com.

Advantages: you don't need a dedicated load balancing piece of software or hardware, so it's less expensive.
Disadvantages: this technique exposes the individual web servers to the end user seeing the site. You can also suffer from duplicate content penalties, too. Finally, if you are relying on the round robin DNS system for load balancing, and a DNS server or one of the Web servers goes down, there's not an easy fail-over (as many DNS records are cached).

More about Round Robin DNS: http://en.wikipedia.org/wiki/Round-robin_DNS

Hardware / Software Load Balancer:
In this case, your DNS zone file tells the end user to go to one IP address when they type in www.domain.com. The hardware or software load balancer then sees the request, and then hands off the content to one of the web servers in a cluster.

Advantages: No duplicate content penalty; to the end user, they just see one web server and not individual sub-domains (www.domain.com and ww1.domain.com). A load balancer can also cache specific items like a CSS page, so the load on the Web server is even more minimal.

Disadvantages: You're introducing another piece of hardware or software (i.e. more cost); this piece could also be a single point of failure into the mix. You need someone to figure out how to set this up and make sure it all works.

More on this type of Load Balancing: http://en.wikipedia.org/wiki/Load_balancing_(computing)#Internet-based_services

Load balancing can get complicated as soon as you have databases involved, but with a good design, multiple front end Web servers can talk to one single backend database server. The goal would be to cache as much content as possible as "static" elements, using caching systems like Varnish, that essentially turn database-driven pages into static, old-school HTML pages. And then only when someone needs to save something from the database (i.e. making a purchase on an eCommerce site), the system then interacts with it.

My recommendation:
(1) Move from the Round Robin Robin DNS to a hardware or software load balancer.

(2) If that isn't an easy solution, implement the Round Robin DNS solution to use identical A records for each server.

For example, you might have identical entries in your DNS zone files for both DNS servers:

NS1.domain.com:

www.domain.com A 69.94.15.10

NS2.domain.com:
www.domain.com A 75.64.18.12

This should at least eliminate your duplicate content issue, but you still do have a few disadvantages (described above). This also could lead to server issues, as the servers might be confused if they are the authoritative ones.

And if both servers are sending email, pay special attention to your SPF record, to make sure that you are allowing both IP addresses to be able to send email. (This is often overlooked.)

Hope this is helpful!
-- Jeff

Robert-

My advice: use the URL structure for the canonical link that does not contain the name-value pairs, such as:
http://www.domain.com/URL-structure/avoid-name-value-pairs/

Don't use the more complicated one like this:
http://www.domain.com/search-query-result.php?id=123&page=42&query=should-you-avoid-name-value-pairs-in-SEO-urls

Instead, go with a short, human readable URL for your canonical link, and you'll have better results.

Here's why I'm making this recommendation:

In the Moz.com guide to the basics of SEO: http://moz.com/beginners-guide-to-seo/basics-of-search-engine-friendly-design-and-development, I'd recommend looking at their URL Construction Guidelnes:

Go static

The best URLs are human readable without lots of parameters, numbers and symbols. Using technologies like mod_rewrite for Apache and ISAPI_rewrite for Microsoft, you can easily transform dynamic URLs like this http://moz.com/blog?id=123 into a more readable static version like this: http://moz.com/blog/google-fresh-factor. Even single dynamic parameters in a URL can result in lower overall ranking and indexing.

According to Google's Official Google Webmaster Central blog:
http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html

"static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls"

Myth: "Dynamic URLs are okay if you use fewer than three parameters."
Fact: There is no limit on the number of parameters, but a good rule of thumb would be to keep your URLs short

Hope this helps!
-- Jeff

When I first read your question, I though that perhaps you might have wanted to personalize content or redirect people based on their geographic location. I've done that before using geo-location information, and the results have been very successful.

But it looks like you want to have a site that will reach people in a specific geographic region. In that case, I agree with Andy (above). You'll need to build pages of content that discuss that region.

For example, your business may be located in Florida, but you may be trying to reach people in Indiana. If that's the case, you don't necessarily need to have a local business address.

Instead, you need to create compelling content that addresses the needs of people in that area.

Let's say that you have a solar power system that you want to sell to people in Indiana, because there are amazing tax subsidies that give the end user 85% savings on an expensive installation. In that case, I'd create content, images, video and more that discuss how the subsidy works, why it's ideal for people in Indiana, and all of that...

I hope this helps!

• Jeff

The only time I've seen this type of thing happen - all of the pages in a site are no longer indexed, yet PPC still works, is when something on the site has been set to no-index / no-follow.

If you had a manual penalty from Google, that would show up in Google Webmaster Tools.  Plus, the site would still be indexed, just ranked really, really low.  If everything was missing from Google's cache, then the most likely explanation is that it was set accidentally to no-index / no-follow.

This is a very easy thing to mess up, and it's possible that someone might have hit the wrong button by accident, or updated the robots.txt file.

In the past, I had a project manager who messed this up for a client while doing a content update on the site, and it was about a week before anyone noticed.  She's no longer here (not due just to that issue).  But this is so critical for me and my company that we've put an automated and human testing check in place each day:

For our company, we have an automated script that runs through all of our sites (and client's sites) each day to make sure that the site is set to index / follow, both on the pages and in the robot.txt file.  We also check the title tag and make sure that the name servers haven't changed.

I also pay someone on my team to run through a 12 step checklist each and every day to make sure that things like the site search are working, contact forms go through properly, and that pages are set to index / follow.

I hope this helps...

Thanks,

-- Jeff

Bryan -

Yes, a fast load time for your pages is a strong signal to Google and other search engines that you care about the end user experience.  People like pages that load quickly.

The http://tools.pingdom.com/ site is a great place to start.  It's free, but you can only do one page at a time.

I would start with your home page, and other top traffic pages, and look at what you can do to better optimize them.  Look at what files and requests from the page load test take a long, long time to load.  Usually this is a common theme across your entire website, so fixing it in one place will help the entire site.

My recommendation would be to use a type of caching system, that reduces the load on the server.  Caching essentials turns a database-driven site (where all of your menu items, products, content, call-outs) require you to hit your database, and turn it into a basic HTML page.

Varnish is a good caching system (free) but there are others, too.  They do take time to set up and configure.  But once you do, it will help all of your pages on the site load much more quickly.

Beyond that, you can try to minimize your CSS using several services, too, and reduce image load times via a CDN (content delivery network).  Many of the top hosting providers will give you CDN access for your media files, either included with hosting or for a small extra fee.  It's worth it and can really speed up a site.

Finally, don't go cheap on your Web hosting.  A $5.95 per month account with Godaddy is not going to perform like a finely-tuned dedicated server that has plenty of memory to handle lots of people hitting your site at the same time.

We once took someone from a 45 second page load time to under 4 seconds, simply by changing their hosting provider.

Hope this helps!- Jeff

Edmond -

I've had this happen in the past, and it can take a while to resolve.

First, go through the site and find out where all of the malware has been uploaded.  It's possible it's in new files, or added to existing files.  It could also be located in the database as well, if it's a database-driven site.  I'd recommend going through EVERY file tree via FTP and look for odd files.  Don't just rely on timestamps, though, as some malware can be uploaded without leaving a "recent" timestamp.

If you haven't changed anything recently, you may be able to just restore the site from an older backup.  That said, sometimes the malware has been sitting on the server, and it hasn't been discovered until recently.

Your hosting company may be able to help.

Once the site is cleaned up, use a third party scanner to make sure it's clean.  I've used this one in the past: http://sitecheck.sucuri.net/scanner/

Then, through Google Webmaster tools, request a new scan.  This can take several long, long days.

While the site is down / inaccessible, consider posting to social media accounts like Facebook, Twitter, LinkedIn, Google +, etc to let people know that you are working on the issue and it should be resolved quickly.

And then wait... until the restriction is lifted...

Yes, Magento does have a way of handling search results that are not always SEO-friendly.

To restrict Google from indexing anything in the /catalogsearch/ directory, I'd add this to your robots.txt file:

User-agent: *
Disallow: /catalogsearch/

Here's a Moz blog about the robots.txt file:
http://moz.com/blog/interactive-guide-to-robots-txt

And also, just in case the "killer" robots ever take over, Google has made sure that their two founders are not able to be indexed by both the T-1000 and T-800 models, with a special killer-robots.txt file:
http://www.google.com/killer-robots.txt

Hope this helps!
-- Jeff

Before you do any testing, I'd recommend first reading this You Moz post, "Are You Hurting SEO with These 5 Split Testing Mistakes":
http://moz.com/ugc/are-you-hurting-seo-with-these-5-splittesting-mistakes

From this article, I'd recommend creating a separate version of your category page, but make sure to:

• No index / no follow the test page
• use rel = canonical on your test page to the control page

I hope this helps!

-- Jeff

Yes, you do appear to have two H1 tags on the page. (I visited the page, and did a view source in the browser.)

The first one is toward the top for your logo:

# Rijwiel Cash & Carry

The second one is here:

Fietsen voor het héle gezin

You might need to either edit the template page, or change the Div to reflect this change. It's the

tag

Hope this helps!
Thanks,
-- Jeff

Bob -

I would recommend looking at Craigslist and other posts for people looking for an SEO position, and also talking to some of the other SEO companies in your town about working for them on a part-time, contract basis.

Many companies don't want to hire a full time employee, but might see a great need for someone 20 hours per month.  Piece together a few of these, and you'll have this taken care of...

Hope this helps...

-- Jeff