Llyod-

I wouldn't recommend the change of address feature. It's meant to be used when you are migrating your main website to a new domain. Your primary (live) domain is intact; you just want to no-index / no-follow your demo site.

The change of address will also only be effective for 180 days, too.

Google recently changed their change of address tool, and Barry Schwartz of Search Engine Land walks through it:
http://searchengineland.com/google-revamps-change-address-tool-within-webmaster-tools-205829

The big takeaway:
"Don't use this tool unless you are moving your primary website presence to a new address."

I hope this helps!
-- Jeff

This happens a lot more than you might imagine.  We've even seen times where end users are placing orders on test sites because they're able to find out-of-stock items from an out-of-date demo site.

If you need to have the demo. store up and running so people can test it, I don't think you need to tell Google about the change of address.  I think that the no-index / no-follow status of the site and the robots.txt should prevent Google from indexing it.

That said, there are a few more ways to protect the demo site:

1. You can password protect it, using an .htaccess file.  This might not be ideal, because testing might prevent you from being able to see the whole site properly on different devices.

2. You could IP restrict the site to a small number if IP addresses, using your .htaccess file.  In this way, only people who are whitelisted are able to do this.  You could even get fancier, and have a form that allows testers to be able to add their IP address to the "allowed" list from a browser.  Anyone else would / could be redirected to the normal site.

3. I'd also recommend putting a banner at the top of the demo site, letting people know that any orders placed there are just for testing and won't be fulfilled.

I hope this helps!

-- Jeff

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

Sam -

Quick question: have you changed your Google+ listing to a Service-area business?

If not, you'll want to set up the business so it not based on the physical location / address (i.e. your business address 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

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

In my opinion, you'll need to work on both. But I'd start with whomever has the highest amount of domain authority and/or traffic first.

But the most likely case is that people will find out about your B2B app from the Shopify / Bigcommerce / 3dcart sites. The fact that your app is listed there creates a lot of trust and confidence, and is likely the first place that people who have that type of shopping cart system will start to look. I'd make sure that you upload as many screenshots, content, etc, and try to get great rating on these sites first.

Your corporate site, though, is the place that people who really want to know more about your company, before they purchase the app, will then go. Your corporate site, though, is less likely to have as a high a domain authority... but you can help reinforce the app listed on the shopify / big commerce / 3d cart sites with strong content and links directly to those pages.

I hope this helps!
-- Jeff

I'd agree with Max.

My initial thought is that somehow, the conversion to purchase tracking code is being triggered (properly) when the end user places an order and gets to the order success / confirmation page.

It's possible that when you are processing the order for shipment, or something like that, you are inadvertently triggering the same code?  It could also be possible that the end user, going into their account to check on shipping status, etc, is re-invoking the trigger for the conversion to purchase / eCommerce order.

I hope that 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

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

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

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

I'll throw my recommendations in for videos:  One  of the most successful video series ever was the "Will It Blend" series:

http://en.wikipedia.org/wiki/Will_It_Blend%3F

(You know a video campaign has gone viral when it has it's own Wikipedia page that documents it.)

Hope this helps...

• Jeff

Laura -

Okay... I took a look at the original page, as well as the page that has the sorting done to it.  In both cases, I was able to see that it had a page title displayed:

<title>Serviced Apartments in Greater London | Central London Apartments</title>

However, I wasn't sure if it was a browser issue, so I ran the URL through the Screaming Frog app, and found that it, too, is seeing valid page titles when items are sorted (please see attached screenshot).

I hope this helps... from my end, it looks like the page titles are showing up properly.

Thanks,

• Jeff

Page-Titles-SEO-Search-Question.jpg

Pablo -

Yes, it would be better to have all of your domain authority under one main domain name, instead of spreading it thinly using subdomains.

Thanks,

-- 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

Laura -

If you can share an instance of one of the pages that has a title tag, but doesn't show up in Moz, that might help to troubleshoot?

It could be a redirect issue with the canonical tags, perhaps... but if you can post something I'd be happy to take a quick look...

-- 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

There are two main ways to do something like this.

1. The easiest way to organize them would be to build a page on your site that has a list of your presentations, and then each presentation you can link to as either a .PDF or .PPTX file (or both).

2. If you really want to take it to the next level, build out each presentation as a page in HTML. Have each slide displayed as a graphic, where they end user can click for the full page view. Place your comments / what you'd say during the talk below each slide, listed on one long page. This is a lot like the Moz whiteboard video talk, where the transcript from the video is below on the page.

I hope this helps!
-- Jeff

So, if this is a huge brand name with a high domain authority...  it honestly won't matter as much how their category and URL structure is set up.

However, if they are using two different directories with specific information about each product, this would be fine as well.  I think that having a site with two big / strong categories, but no general categories should be okay, especially if their DA is really strong.

Hope this helps!

• Jeff

Microsites can either be a separate domain name (i.e. www.domain-light-tablet-laptops.com) or a subdirectory off of your existing domain (i.e. www.domain.com/light-tablet/)

It sounds like you're going with the subdirectory option for the microsite. I think that this will be helpful, and add more SEO value to the microsite. Here's a link to a post on subdomains vs. subdirectories:
http://moz.com/community/q/revisited-the-subdomain-vs-subdirectory-question

My recommendation, if you are to use a sub-directory, would be to have one top level, such as:
www.domain.com/light-tablets-laptops/

If you don't need to have the home.asp, that might be better... but that's going to depend on your site and page system settings.

For your categories, you might go with:
www.domain.com/light-tablets-laptops/manufacturer/

And for your product, you might go with:
www.domain.com/light-tablets-laptops/manufacturer/tablet-XYZ/

For the contact page, I'd go with:
www.domain.com/light-tablets-laptops/contact/

Hope this helps!

Thanks,
-- Jeff

Marcel -

I do see on your site that if you start the process of purchasing, you are on the http://www.smartphonehoesjes.nl domain.

But when you go to checkout on the site, the checkout page is here:
https://smartphonehoesjes-nl.webshopapp.com/checkout/method/

You have a subdomain of the Webshopapp.com.

The challenge with this is that cookies set from the www.smartphonehoesjes.nl won't be able to be accessed when you move over to the *.webshopapp.com domain.

You could get around this if the Webshop App system allows you to add tracking codes, such as a conversion tracking code as a 1 pixel x 1 pixel iframe on their site, and then you can read and set the cookie from there.

Or, you could migrate your checkout page to the main domain, so that you're not taking the end user to a different domain for the checkout process.

Hope this helps!
-- Jeff

For Adwords, there's two different URLS you need to know about:

Display URL: what shows up in the ad at the bottom
Destination URL: what page the end user actually is taken to

According to Google's Adwords Policy here:
https://support.google.com/adwordspolicy/answer/6021546?hl=en

"The display URL for your site cannot be an IP address (such as 123.45.678.90) or use non-standard characters (such as !, *, #, _, @)."

Hope this helps!

-- Jeff

Wayne -

My hunch is that YouTube might be a tad faster, but why rely on guesswork when you can do a very easy test?

Create two versions of the page, one with the YouTube version, the other with Vimeo, and run them both through external page testing sites, such as http://tools.pingdom.com/ ... and see what happens.

It would be wonderful if you could report back to here what you've found...  If you're worried about duplicate content, you can always no-index one of them.

Thanks,

-- Jeff

Chris - I wouldn't worry about duplicate content on the privacy policy.

I have, though, seen where people copy-paste from another site, but forget to remove the other company's name.  (That's a little embarrassing, though.)

Just my $0.02,

-- Jeff

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

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

Steve -

I just received one from Google yesterday that I think I deleted, but we are Google Partners.  Message me and I'm happy to send it over to you...

Thanks,

-- Jeff

Brandon-

I'm a big fan of optimizing images to use descriptive names; it seems to have worked quite a bit in the past. Search engines often will look for contextual clues about the content of an image, and this includes ALT tags, photo captions, and the image name.

In a Moz blog posting by Kasy Allen in 2011:
http://moz.com/blog/is-optimizing-photos-more-important-than-you-think

"The Google image bot definitely seems to be looking at filename and the alt tag, but it also looks at a lot of the same factors that the Google search bot looks at - title tag, meta description, heading tags, links and anchor text. If we are already focused on optimizing our individual pages, maybe it's time to remember that image optimization is just as important. Oh, and it also seems to be important that you host your own images, but you already knew that, right?"

I've found that it's best to name each image during the product creation process. It's nice to have the product name and SKU in the image, and I also like to use directories, too.

So if a product named Canon 50 mm f/1.4 lens in category Canon Camera Lenses, you might want to name it here with this directory structure:

http://www.domain.com/images/canon/DSLR/lens/canon-50mm-f-1.4-lens.jpg

But if you need to do this in a bulk fashion, you can create the category and directory structure using a spreadsheet and the concatenate feature. You can also do a find-replace on spaces in a product name to insert dashes, etc.

See the screenshot here: http://www.customerparadigm.com/images/moz-screenshots/concatenation-bulk-renaming.gif

You could also use LightRoom or Photoshop to help automate photo names as well.

I hope this helps!
-- Jeff

I grew up in St. Louis, so I might have a little bit of insight...  It is possible that St. Louis is spelled differently by different people, but most normal users who live in the area are not spelling out "Saint."  Google's ability to show synonyms and close words should obviate this issue, too.

While St. Louis - the city - has had a bit of a resurgence in recent years, become more urban and hip,  most of the population of the St. Louis metro area doesn't actually live in St. Louis, and probably doesn't use "St. Louis" in broad search terms.  The population of St. Louis is actually quite small.  Instead, the city is surrounded by many smaller cities that people might identify more specifically with.

For example, people might use Chesterfield, Creve Coeur, Ladue, etc, as a much more detailed way to search.

I hope this helps!

-- Jeff

No worries.  On that page, I did find two there:

Giant Futuro CS 3 2014 Bruin Heren

It does look like the site is running Magento Community 1.7.  You'll probably need to dig a bit to find this, but you could looking the design files for the theme, as well as perhaps in the static CMS blocks for the site.

If you'd like to run a Magento Code Audit on your site, we developed one that we offer for free; it might tell you if you have core file modifications or base file changes that might help you find the appropriate files.  Here's the link:

http://www.customerparadigm.com/magento-development/free-magento-code-audit-report/

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

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

My recommendation would be to do a DNS zone file lookup on the domain name.  You could use an online tool like this:

http://www.mydnstools.info/nslookup

... and see if the IP addresses match in the "C" or "D" blocks: AAA.BBB.CCC.DDD

Hope this helps!

• Jeff

Peter -

If each of the 10 websites are able to stand on their own, I think a strategy of slowly linking a few together might work, but I would be cautious.

I would avoid having each of the 10 websites link to each other. That's probably where you'll get into the most amount of trouble.

Instead, draw a diagram with the Websites that visitors would feel are the most similar. And test and watch the traffic. If you see a high bounce rate from one site to the other, you might want to reconsider.

I'd also evaluate if the sites that you are linking together are hosted at the same location, with the same C block of IP addresses. If so, that could raise a virtual eyebrow or two with an algorithm.

You might want to go with a strategy like this, where site 1 links to sites 2, 3 and 4:

1
+---+----+
2 3 4

And site 5 goes to site 6

5
+-----+
6

But don't go with a strategy where:
1 -- 2 --- 3 --- 4 --- 5 -- 6 -- 7 -- 8 -- 9 -- 10

Hope this helps!

-- Jeff

I would test this, and it might work differently according to your server setup, but you could try the RedirectMatch command like this if your site uses mod_alias:

RedirectMatch 301 ^/dummy.php/.*$ http://www.domain.com/

Or with mod_rewrite, this might be the way to go:
RewriteRule ^dummy.php/ http://www.domain.com/ [R=301,L]

I hope this helps!
-- Jeff

It's not ideal to have such a massive .htaccess file that it slows down your page load time significantly.  But if you have a lot of inbound links to pass that matter, you'll likely want to keep your SEO value intact and use 301 redirects to handle this properly.

My $0.02: Test!

Do a page load test with the .htaccess file off / removed, and then do another one where it is on and live.  If there's no significant time difference, you should be okay.

We have sites with hundreds or even thousands of lines in the .htaccess file and they run pretty quickly.

That said, here's why 404 pages aren't ideal to serve:

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.

Finally, 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

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

Dan-

As the business is not based on the physical location, but serves a greater area, you need to set up your Google+ account as a Service-area business on Google.

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

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

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

Kyle -

Sorry this is so puzzling.  The only other thing I could think of is that perhaps the older pages still somehow exist and/or are being served by the server?  For example, the .htaccess file might have the /old-page.php redirecting to the /new-page.php... but somehow the old-page.php is still accessible?  I'd also look at caching, too? For example, our site, www.CustomerParadigm.com uses varnish for caching, so if we make a change to the site, we need to clear out that page or the change won't be reflected publicly.

Hope this helps?

-- Jeff

I'd also recommend putting in an IP restriction for any of the demo sites.

So that if anyone visits the demo sites from a non-whitelisted IP address, then you can display an error message, or simply redirect them over to the live site.

That will likely have the search results quickly removed from the search engine.

Hope this helps!

-- Jeff

Without seeing the new and old sites, my first impression is that this might have been caused by having the older site on a different server; the newer site might be on a newer, different Web server.  If this is the case, and the older server is still online, I'd check your DNS zone files to make sure that the older site isn't somehow still accessible?  I've seen cases where there's two A records for the www. version of a domain; not ideal, but it can cause issues.  I'd also set the robot.txt file on the older server / older site to no-index / no-follow.

Hope this helps?

Thanks,

• Jeff

Ryan -

There are a lot of different ways to fix this, but I think that my first, initial suggestion would be to take control over the Google + pages for both locations, so that you can verify these addresses, and fill them out with more information.

For LTI Inc, the Google + page seems to say, "Is this your business?"  (See screenshots.)

This is where I'd start.  Once these pages are verified, it will be a lot easier to tie everything everything together.

I hope this helps!

-- Jeff

lynden-transport-SEO.jpg lynden-transport-SEO2.jpg

It sounds like it could be a few different issues, but my initial look at the site makes it seem to me that it's duplicate content, and that Google is only returning the results for their PDF and not for yours.

Google does hate duplicate content, and this is probably why they are only showing their PDF.

It may be that they posted theirs first, or they linked to it first.

As you probably know, not all PDFs are created equally. Some are more difficult for a search engine to read (i.e. might have text tied up in graphics). And PDFs are really not a great end user experience.

If you really want to rank for this, I might suggest creating this page as an HTML page instead of a PDF, as it might be able to be indexed more easily, and you might rank for it better.

I hope this helps?

Thanks,
-- Jeff

Max -

Yes, this was for a non-profit, religious organization to promote an important holiday event that was $36 in price.  I can't share the conversion data, but it reached a significantly new audience in a 25 mile area around the city, with lots of conversions, a ton of impressions.  Honestly I didn't even pay attention to the Facebook likes, as it didn't really matter to this campaign.    I'd be happy to discuss more offline, though, if you want to message me.

Thanks!

• Jeff

Yes, that is indeed strange.

I just ran a very successful campaign on Facebook recently, and it did garner more likes.  Although that wasn't the intention of the ad, and I didn't do any testing during the pre-approval campaign to track likes.

I think it's people like you, who measure and track everything, that help unravel some of the mystery behind some of these new systems that are fairly opaque to the outside world.  So well done...

I have an upcoming Facebook campaign that I'm poised to run soon, and will do some additional tracking and measurement on this issue.

Thanks!

• Jeff

Max - That's indeed interesting.  Quick question, though... did the Facebook "Likes" stay on the sites, or did this number decrease?

I wonder if part of Facebook's automated testing procedure is to crawl the site with their internal systems, and make sure that the page mentioned in the advertisement works properly, in order to combat fraud / phishing / cross-liking?

Most of the research out there has more to do with combatting fake "Likes" that people buy from companies, and how this can affect a business:

http://searchenginewatch.com/article/2329878/Facebook-Ad-Fraud-How-Can-Advertisers-Combat-Paid-Likes

Ruben -

Yes, I'm not a big fan of "Home."  The title tag is what shows up in Blue Underlined text at the top of a Google listing.  Depending on what the site is all about, you usually want to have your company name and a very short description of what you do.  I see you posted as Kemp Ruge Law Group; if it was for that site, you might have:

Title = Kemp Ruge Law Group - Specializing in XYZ Law in City, State

There are other ways to go; some people advise putting your specialization first, and the name second.

But either are way way better than "Home."

Rikomuttik-

If you do, indeed, have inbound links from other sites pointing over to your site, this is a really good thing.  This often happens when people want to link to an article, image or other page within the site.

I'd do a crawl on Open Site Explorer, or within Google's Webmaster Tools, and see if you can find any inbound links that are pointing to non-existing pages, and your system is giving 404 errors.

Then, I'd use a 301 redirect to take the inbound link and direct it to the proper location.  Or, if you really want, you can re-create the page at the older location, but just make sure that you're not creating duplicate content on the site.

Hope this helps!

• Jeff

Rikomuttik-

There are a couple of reasons why 404 errors might be showing up again, even if you've fixed them in Google.

1. Moz might be using an older crawl that still lists pages that don't exist on the site.

2. If you're using a soft 404 error handling (i.e. all 404 errors redirect to the home page), then Google might not see the errors, but perhaps Moz does?

3. It's possible that you have inbound links from other sites that point to your site, that is throwing 404 errors, and that's what it being seen by other search engines.

4. It's also possible that the 301 redirects you might have set up in your .htaccess file have been changed, or are no longer working?

5. It's also possible that an older page that used to be on the site, was removed, was added back in, and that page has links that go to 404 pages?

Hope this helps?

-- Jeff