The Real Reason Google Turned off Keyword Referrals for Logged in Users?

by Kevin Spence

If you work in the search marketing world, you know the story by now — Google has decided not to pass in keyword data when users are logged into their Google accounts. The last part of that sentence (in bold) is incredibly important, and we’ll get to that in a minute.

Google claims that they’re making this change for privacy reasons — and strangely predictably, nobody believes Google. But I do. And I will tell you why.

But before we go down that path, let’s get a couple things straight: This isn’t about premium analytics packages. This isn’t about other advertising networks using Google’s keyword data for retargeting. This is about how Google grossly compromised user privacy for more than one month for the sake of getting a product to market as quickly as possible.

And now they’re trying to clean it up before anyone notices.

The REAL Privacy Problem

From September 15, 2011 – October 18, 2011, it was possible for any webmaster with a hacker-leaning mindset to do something we never could have imagined before: to tie an individual Google search back to the actual human being who typed it into their search box — if that user was logged into their Google account.

Take a second to think about the impact there. We use Google to find help for private and sensitive things that we don’t want others to know. We put a great deal of trust in Google to keep our searches private. The thought of our privacy being compromised is scary enough on its own — but it’s even scarier when you realize that this wasn’t even a hack.

Google provided all of the tools anyone would need to do this.

They made it possible by launching the Google+ API before it was safe.

How it Worked

As with all social APIs, developers using the Google+ API can access public parts of any user’s profile data.

So for one month, each time your keyword data was passed through in the referrer to a given website and you were signed into your Google account, anyone could write a simple program with the API to tie YOU back to the search that brought you to the site.

By closing keyword referrals for logged in users, Google is cleaning up the gaping privacy hole that left our searches exposed for over a month.

How do you think the FTC would feel about this? What about privacy advocacy groups? The United States Congress?

It’s no wonder that Google has remained uncharacteristically silent on their motivations for making the switch.

Google Hasn’t Gone Far Enough

By blocking keyword referrals for logged in users, Google is taking good steps towards cleaning up this privacy mess — but they need to go all the way.

First, I know my PPC friends won’t like to hear this, but if Google wants to make things right, they need to close off the referring keywords for Adwords customers as well. Sorry, it sucks, but you’ll learn to deal with it.

Second, Google needs to come clean. All of their users have a right to know.  A vague post on their Analytics blog just isn’t going to cut it.

{ 2 comments }

How to Run Multiple Domains from a Single WordPress Install

by Kevin Spence

In this tutorial, I will walk you through the installation of WordPress Multisite and explain how to configure it so that you can run multiple domains from the same WordPress installation.

Why Use WordPress MultiSite?

Managing multiple sites from the same WordPress installation has a lot of nice advantages.

One of the basic advantages is that you won’t have to install the same plugins over and over again as you start new sites (this is especially helpful if you’re using plugins like Akismet or Gravity Forms where you always have to hunt for your license/API keys). Now, you can just network enable your plugins and use them on any site you want to. You also won’t have to upgrade multiple WordPress installations whenever a new version is released — a single click of the button will get all your sites completely up to date. And adding a new domain takes only a minute.

There are many advanced possibilities as well. If you’re a developer, you’re probably familiar with the pains of maintaining multiple code bases, or upgrading multiple instances of the same theme thanks to the hell that is cross-site PHP scripting. Well, you can kiss those pains goodbye now. We’ll be setting up virtual sites here, so you’ll be able to access the same files/themes/plugins/whatever you want from any site on your WordPress installation — this is powerful stuff.

Please Note

This is a relatively advanced tutorial as far as most WordPress tutorials go. You don’t have to do any programming, but you will have to make some edits to files that will completely crash your site if you make a mistake. A basic understanding of htaccess and php is recommended.

Requirements

  • Your existing WordPress installation *must* be in the root of your site (not a subdirectory like /blog ).
  • You must have access to a control panel like cPanel or Plesk.
  • Your host must allow the creation of subdomains.

Before You Begin

At this point, it’s a good idea to go ahead and set your DNS settings on the sub-sites that you want to work with (ie: you want to add mysite2.com to the mysite1.com installation). This should ensure that the DNS propagation will be complete by the time you complete this tutorial.

The nameservers on your ‘secondary’ sites should match those of the root domain (mysite1.com) that we’ll be working with here.

Installing WordPress Multisite

One of the nice things about post 3.0 WordPress is that MultiSite is prepackaged, just waiting for you to enable it — much like a War of the Worlds invasion.

To enable WordPress Multisite, open your wp-config.php file and add the following line directly above where it says /*That’s all, stop editing! Happy blogging */

define('WP_ALLOW_MULTISITE', true);

There are two primary options that you need to be aware of when configuring MultiSite:

  1. Your sites can be in subfolders ( /blog/) or
  2. Subdomains ( blog.yoursite.com )

If you want to run multiple domains on the same installation, you’ll need to use subdomains. To ensure that all new sites you create are setup as subdomains, add this line to wp-config.php as well, directly below the command above.

define( 'SUBDOMAIN_INSTALL', true );

Create a New Directory

Before you can enable your network of sites, you will need to create a directory named blogs.dir inside your /wp-content/ directory. This is the directory that will be home to all of your uploaded media files (images, etc). Make sure that the blogs.dir directory has the same permissions as your /wp-content/ directory (most likely 755).

blogs dir

Enable Your Network

Now that you’ve created the blogs.dir directory, you need to enable your network of sites in WordPress. To do so, login to WordPress and click the Network Setup link on the left hand nav:

wordpress network setup

Note: You will have to temporarily deactivate your plugins to successfully enable the network. Don’t worry, it will only take a minute.

Once you’ve deactivated your plugins, enter your Network Title and email address into the form and click the Install button.

wordpress network

You will now be presented with either two or three text boxes filled with code (depending on your original wp-config setup). These are simple copy+paste jobs.

Follow the instructions preceding each text box — you will be editing your wp-config.php and .htaccess files. Be very careful, and make a backup of each file before editing: making a mistake in either of these files will completely crash your site.

When you finish making the changes and verify that your site is still running, you will need to logout and back into WordPress.

When you log back in, you’ll need to make sure that you’re in the Network Admin and not Site Admin. To switch to Network Admin, mouse over your username at the top right of your WordPress admin UI, and you’ll see something like this:

network admin

Select Network Admin from the list, and then go ahead and reactivate your plugins (Network Enable any plugins that you want to use on multiple sites).

Enable Wildcard Subdomains

Before you can create new subdomain sites that actually work, you’ll need to enable wildcard subdomains. If you’re using cPanel, you can enable your subdomains by navigating to your site’s control panel (click List Accounts on the left nav, and then the cPanel icon next to the site you want to add the subdomain to) and adding a new subdomain. To add a wildcard subdomain, put a * in the subdomain field as pictured below.

Also, make sure that you set the value of the Document Root field to the root level of your WordPress install (which should be the root of your site).

wildcard subdomain

If you’re using Plesk, follow these instructions.

Install WordPress MU Domain Mapping Plugin

The WordPress MU Domain Mapping plugin will handle all of the redirects needed to turn your subdomains into real domains of their own. Either download it here or install through your WordPress UI.

Once it’s installed, you will need to make some manual adjustments.

1. In your FTP client, navigate to the WordPress MU Domain Mapping directory. Download sunrise.php to your desktop, and re-upload into /wp-content/. If you already have a sunrise.php file (you probably won’t), you will need to merge the two.

2. Edit wp-config.php and add this line above the last “require_once” command:

define( ‘SUNRISE’, ‘on’ );

Set WordPress MU Domain Mapping Options

In WordPress (still in Network Admin), go to Settings->Domain Mapping.

On the following screen, you will presented with the options below. I have found that the following settings work well for my needs:

domain mapping options

Adding a New Domain To Your Network

In WordPress, go to Sites->Add New

Enter the subdomain for this site, your site’s title, and your email address.  Here’s how I set mine up:

add site

When finished, click the Add Site button.

Now go to Sites->All Sites. Mouse over the new subdomain you just created, and watch the tooltip at the bottom of your browser to see the destination URL. You’ll see a URL parameter called ‘id.’ This parameter stores that site’s unique numerical ID. Write it down — you’ll need it in a second.

Now we’re ready to configure the domain mapping in the WordPress MU Domain Mapping Plugin.

Configure Domain Mapping

In WordPress, click ‘Domains’ from the Settings section of the left nav. When the page loads, focus your attention on the ‘New Domain’ section of the page. Here, there are two fields. One is the site’s ID (the unique number you wrote down a second ago) and the domain. Basically, you are telling the plugin that the subdomain behind Site ID x should resolve to the domain you’re putting in the Domain box.

Here are my settings:

domain mapping

Once you have things the way you want them, click the Save button.

Park Your Domain

This is the last step (woot). Here, we’re going to park your secondary domain (mynewsite.com) on top of your primary domain (in my case, makeitrank.com).

If you’re using cPanel, navigate to DNS Functions -> Park a Domain.

dns functions

Here, we’re parking the new domain on top of the ‘root’ domain we’re already running WordPress on.

park domain

(I scratched out my username in the screenshot above because…well…it wouldn’t be secure to show you that, would it?)

Click the ‘Submit’ button, and check on your site. Your new domain should be running perfectly.

In Closing

From here on out, when you want to create a new site all you have to do is:

  1. Add a new site within WordPress
  2. Set the DNS on your new site to match the settings on the ‘root’ site
  3. Configure the site in the Domain Mapping plugin
  4. Park the new domain on top of the ‘root’ domain

I hope you found this useful. If you have any questions/comments, leave them in the comments below.

{ 5 comments }

How to set Canonical HTTP Headers

by Kevin Spence

It’s been a few weeks since Google announced support for canonical links using HTTP headers. Aside from the obligatory articles announcing the news, the SEO community has been pretty quiet about this new development — and I’m a little surprised.

This is a really big deal that could positively impact thousands of sites, yet I haven’t seen any tutorials cropping up on *how* to set the header.

I suspect the silence is largely due to people’s uncertainty about when or how to use canonical HTTP headers, so I’ll take some time to explain both when to use them and how to use them (scroll to the bottom of the post for a code sample if that’s what you’re after).

When to use Canonical HTTP Headers

In a nutshell, you should use canonical HTTP headers whenever you need to set a canonical tag on a non-HTML document.

If you’re still not sure when to use them, consider this example:

A lot of businesses like to publish case studies on their sites, and they often publish two versions: an HTML version and a PDF version. This is fine — it’s nice to offer your users multiple formats so they can choose the one that’s best for them.

The only problem is that PDF versions often outrank the HTML versions, which is ok — but it’s less than ideal for many sites. PDF downloads won’t show up in your analytics (unless you’re looking at weblogs, which few site owners do), and they don’t contain lead forms/other nice things that our websites use to generate income. In short, you’re potentially missing out on a lot of things if your HTML content is getting outranked by a PDF. Canonical HTTP headers will help with that.

Tutorial: How to Use HTTP Header Canonicals with htaccess

For a lot of people, HTTP headers are something of a mystery — they just sort of magically happen. The good news is that they’re really easy to understand and even easier to control. When it comes to setting the canonical on non-HTML documents, the easiest way for most people to control the headers is through your htaccess file.

For the sake of this example, let’s say that I have a PDF named my-file.pdf in the root of my site — and for some reason, I want to set the canonical to my homepage (not a good idea, but it makes the example simpler).

All I would need to do to make this happen is add the following code to my htaccess file:

<FilesMatch "my-file.pdf">
Header set Link '<http://makeitrank.com>; rel="canonical"'
</FilesMatch>

Once you’ve added that to your htaccess file, you’ll want to test your header to make sure that it’s correctly.

To test it, pop open the Net tab in Firebug or a use a specialized plugin like Live HTTP Headers and then open your PDF (or other document) if your web browser.

This is what the canonical header looks like for my example — yours should follow the same format:

canonical http header

That’s it! I hope that you see the power in controlling canonicals this way — it’s a fantastic way for us SEOs to control the weight of all documents in a way that was never before possible.

Note: This method is fine if you want to set only a few headers (if you have a lot, your htaccess file can get very big very quickly). I have not included an example of handling many canonicals with a single command, because it will need to be algorithmic in nature and the code will be largely dependent on the file structure of your individual site.

{ 0 comments }

How to mask affiliate links from a datafeed

by Kevin Spence

One of the more common affiliate marketing tips is that you should mask your outbound affiliate links by pointing them at an internal URL, and then redirecting to the affiliate link. This should be done for a variety of reasons, and it’s an easy thing to do when you’re working with just a handful of links — but how do you make it work with a product feed where you don’t know what the link will be before you grab it?

Fortunately, masking affiliate links from a feed is easier than you think, and I’ll show you how to do it.

I only make two assumptions in this article:

  1. You already know how to parse a product feed (I can write a separate tutorial on this if there’s enough interest).
  2. Your server is running Apache and PHP is installed. Affiliate URL masking can certainly be done in other platforms/languages, but here we’ll be working with PHP and htaccess because a) it’s what I know best and b) affiliates love them some WordPress.

Getting Started

The first thing you’ll need to do is think of a dummy directory off the root of your site — this is going to be where we point our affiliate links. You can name it anything you want to, but it’s important to make sure that this directory is not actually used anywhere on your site — else you’re going to break a lot of stuff. For the sake of this example, I’m going to name my directory ‘product.’

htaccess Rules

Open up your htaccess file and add the following two lines of code (just be sure to replace ‘product’ with the name of your dummy directory, and amazon.com with the domain you will be redirecting to):

RewriteEngine on

RewriteRule ^product/(.*)$ http://www.amazon.com/$1 [L]

Save your htaccess file and close it — we’re finished here.

Manipulate the link from the feed

Now we just have to use PHP to take the product URL given in the feed and make it look like an internal link.

At this point, I’m going to assume that you’ve already parsed the feed and have stored an affiliate product URL in a variable called $url. The following line basically does a find and replace in the URL, swapping out the destination domain with your own, and adding your dummy redirect directory:

$myurl = str_replace("www.amazon.com/", "mysite.com/product/", $url);

Now when you create a link with your $myurl variable, it will automatically redirect to the product page given in your feed.

As a note, I would strongly suggest slapping a nofollow on these links, and also blocking the product directory via robots.txt.

{ 0 comments }

← Previous Entries