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.

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

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:

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.

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:

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

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:

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:

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:

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.

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

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

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:

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.

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.

There’s a lot that you can do with an htaccess file, and of course, things can get pretty advanced in a hurry. Here, we’re going to keep things pretty simple. These are the 10 basic htaccess hacks that every webmaster should know.

1. Force Caching with htaccess

Use: The following htaccess code won’t help the initial pageload, but it will significantly help subsequent pageloads by sending 304 status when requested elements haven’t been modified.

FileETag MTime Size
ExpiresActive on
ExpiresDefault “access plus x seconds”

I generally set the cache for one day (86400 seconds). You can also set different expirations for each file type by breaking each file type up into separate ExpiresByType lines such as:

ExpiresByType image/gif “access plus x seconds”
ExpiresByType text/css “access plus x seconds”

Simple!

2. Set a Custom 404 Page with htaccess

Use: I think this one is self explantatory. Just change ‘/notfound.html’ to match the path to your custom 404 page.

ErrorDocument 404 /notfound.html

3. Implement a 301 Redirect with htaccess

Use: If you have permanently changed the URL structure on your site (via either optimization change or CMS migration), you will want to implement 301 redirects from the old URL to the new URL.

The syntax for a basic 301 redirect is:

Redirect 301 relative/path/to/oldurl/ http://www.domain.com/newurl/

Explanation:
The first URL should be a relative path to the old URL and the second one should be an absolute path to the new URL.

4. Only allow specific IP addresses in certain directories

This is especially useful for admin directories. I generally set my home IP and work IP as the only allowable IPs who can even attempt a login. Unlike other .htaccess hacks, this one doesn’t work from the root folder. You will need to create a new .htaccess file, put the following code in it, and upload it to your admin directory.

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName “Example Access Control”
AuthType Basic

order deny,allow
deny from all
allow from xx.xx.xx.xx

To allow a second IP, just add another ‘allow from’ line.

5. Prevent Image Hot Linking with htaccess

Removed. Here is a MUCH better way to go about this thanks to Maurizio Petrone

6. Enable gzip with htaccess

Gzip is a means of compressing the files on your server so they will load faster. To enable gzip, just

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip

BrowserMatch bMSIE !no-gzip !gzip-only-text/html

7. Remove ‘category’ from a URL with htaccess

Many content management sytems use the ‘category’ URL segment. For instance:

http://makeitrank.com/category/category-name

Well, that’s fine, and it’s necessary to make the CMS work the way it’s supposed to, but it doesn’t need to be visible to do its job. Just drop the following code into your htaccess file to get rid of it.

RewriteRule ^category/(.+)$ http://www.yourdomain.com/$1 [R=301,L]

8. Define any page as the home page with htaccess

You can set any page as the homepage by adding the following to the htaccess file in your root directory.

DirectoryIndex myfile

9. Disable Directory Browsing

You want to keep people out of any directories that might reveal security weaknesses — for instance, plugin directories.

You can block vistors from browsing the directories by adding the following line to the htaccess file in the directory you’d like to block:

Options All -Indexes

10. Protect your htaccess file

Lastly, you want to protect your htaccess file. Hopefully your host has protected it for you, but you can’t be too safe with these things. The following hack will prevent anybody from accessing your htaccess:

<Files .htaccess>

order allow,deny
deny from all

</Files>

Are there any useful htaccess hacks I’ve left out? Let me know!

Google is less than forthcoming when it comes to checking backlinks with the link: command. Their data is generally incredibly outdated and incomplete, and probably with good reason (I assume they want you to use webmaster tools to check your own backlinks, and their web spam team probably doesn’t really want you to build links by checking the backlinks of your competitors). Thankfully, Yahoo gives us a great way to check backlinks for any site on the internet.

Basic Yahoo Backlink Checking Syntax

The best way to check backlinks in Yahoo is with the linkdomain: command, which will show backlinks for your entire domain.

You use the linkdomain command like this:

linkdomain:mysite.com

While that is pretty good on its own, if you spend much time looking through the results, you’ll notice that internal links are also listed, and that isn’t really helpful.

To remove internal links from the results, you just have to tell Yahoo to ignore them. You can do that with the -site:mysite.com command. So if you wanted to see all backlinks for a site without the internal links listed, the entire command would be:

linkdomain:mysite.com -site:mysite.com

Removing Specific Domains from Backlink Search

Just as you can remove your own site from the backlink search by using the -site: command, you can also remove any site of your choosing from the results. This is especially helpful if you have some sitewide links from certain sites that are clogging up your results and making them difficult to weed through.

The syntax here is exactly the same as above, but note that you can remove inbound links from more than one site at a time:

linkdomain:mysite.com -site:mysite.com -site:linkingdomain1.com -site:linkingdomain2.com

Removing Backlinks from Pages with a Particular Keyword Phrase

While it may not sound particularly useful to remove results based on keyword phrase, I have found many good uses for it. For instance, I have had some entries scraped, or syndicated around the internet that resulted in hundreds of backlinks, all with the same title. So if I wanted to see the backlinks without that title in the results, I would use:

linkdomain:mysite.com -intitle:the syndicated title

You can also choose to remove backlinks that have certain words in the URL with:

linkdomain:mysite.com -inurl:keyword