I’ve just been dealing with an issue on a site where Google Analytics is logging a lot of pages twice, once normally and once with a double slash—”//”—at the end.

Obviously this is worrying. If Google is seeing the same page in two “places” via two technically different URLs, duplicate content penalties and PageRank squandering are distinct possibilities. It also seems to break a lot of the Analytics “Site Overlay” functionality.

Here I’m going to go through what I’ve done to isolate the cause of the issue, and approaches to fixing it.

Ruling out the obvious

Naturally I combed through our sitemap.xml (generated by the Google XML Sitemaps WordPress plugin)—no double slashes in there.

Also, I did a site:domain.com type search in Google, and searched through all the returned URLs. No double slashes there either. This suggests that the worst possibility is thankfully not an issue—Google doesn’t appear to be indexing multiple versions of the same pages. It appears to be an Analytics-specific thing.

Possible cause #1: Bad incoming links

I don’t think this is the issue. I pinpointed the referring URLs for a few of the double-slashed entries in our Analytics, and the links are fine.

Possible cause #2: Bad .htaccess redirects

There are quite a few 301 redirects in our .htaccess file, because this site is a revamp where many URLs have changed. I was worried that some might be badly formed and redirecting with extra slashes. However, the above test pretty much rules this out, too. Clicking on the referring links above went through fine. If a redirect was rewriting external links, this would have been visible in actually clicking through that link in a browser.

Probable causes: A single bad internal URL and an Analytics mystery

I used Xenu to check internal links, and found one instance of an internal link with double-slash at the end. It was the top-left link back to the front page on the WordPress login page of a sub-site that runs a separate WP installation from the main site in the root.

This seemed to point the finger at the generally excellent qTranslate plugin—which is installed on this sub-site, but nowhere else. The “back to blog” links on other WP installations were fine.

As part of handling multiple language versions of the same WP content, qTranslate uses URL suffixes, such as /de/. This “back to blog” link is output with the WP bloginfo('url') function (followed by a hard-coded trailing slash). This function returns the blog URL entered via WP’s settings, which should be entered without a trailing slash. There was indeed no trailing slash in our setting, so it seems that qTranslate’s filtering of the bloginfo('url') function must be mistakenly adding a trailing slash where one isn’t expected.

I’ve no idea how, but it seems that this single instance of a double-slash was being picked up by Analytics, and was proliferating through other logged data.

Solution #1: Fixing the trailing slash in WordPress

First step was to remove the extra slash from the results of the bloginfo('url') function. Looking at the qTranslate forums, others seem to have noticed this issue. Hopefully it’ll be fixed soon, but until then, placing this code in your WordPress theme’s functions.php file should make sure this function returns the right URL:

function fixblogInfoURL( $result = '' ) {
	if ( substr( $result, -1 ) == '/' ) $result = substr( $result, 0, -1 );
	return $result;
}
add_filter( 'bloginfo_url', 'fixblogInfoURL' );

Solution #2: An Analytics filter

This Analytics support thread ends with a suggestion to include a search/replace filter in your Analytics profile. As all my testing seems to show this is a problem internal to the Analytics system, this seems like a good approach. I’ve only just set this up, so I’ll report back if any problems come up with this. Please let me know how it’s worked (or not) for you!

Solution #3? Rewriting

Searching on this issue will bring up multiple suggestions for .htaccess rewrite code to replace double slashes with single slashes.

I can see the logic in this, but as my testing seems to indicate that this is a case of one or two bad URLs mysteriously spreading through the Analytics system (and not through Google’s index or anywhere else), it seems sufficient to isolate those bad URLs, fix them, and add an Analytics filter.

Again, I’ll report back if this rewrite approach ends up being necessary; and again, let me know your experiences if they differ.

UPDATE: I’ve decided it’s best to include a .htaccess rewrite just in case. Thomas Scholz suggests one way below. I’ve actually ended up using this one at yoast.com.

Postscript: The Default Page setting

9/11/09: Thanks to Gavin Doolan’s comment, this problem has become a little clearer. On the Google Analytics profile in question, the “Default page” setting was set to “/” (one forward slash). It seems now this was wrong, and at least part of the problem.

Now, since I implemented the above fixes, our stats stopped registering double-slash URLs completely (even with the default page set to “/”). They’re still in the stats from before the fixes were applied, but hits dropped to zero after the fixes. Maybe the rewrite was saving Analytics from registering double-slash URLs. Maybe there was some other factor at work other than the default page setting (which certainly seems possible given the confusion I’ve seen on forums about this issue).

However, even with the double-slashes not registering in terms of hits, the Site Overlay feature just wasn’t working. It registered no hits on any links—and when you hovered over any link, there on its end was the dreaded double-slash. Now that the default page is left blank, Site Overlay is back to normal. I suspect and hope that this is the last nail in this issue’s coffin!

Image replacement involves using CSS to hide the text for an element (e.g. a <h1>), and setting the background-image for that element to replace it with an image. Users with visual browsers with CSS get the image; text-only browsers, bots, etc., just see plain text.

It’s not without its detractors and slight drawbacks, but it’s a widespread technique. A quick scan of big-name sites as of writing found it in evidence on stopdesign.com, mezzoblue.com and adobe.com.

However:

Hiding text or links in your content can cause your site to be perceived as untrustworthy since it presents information to search engines differently than to visitors. (Google Webmaster Help Center)

This obviously caused some panic among developers using image replacement. While Google seem to have made some comments saying that they would distinguish between legitimate usage and spamming, they’re pretty vague about what constitutes one or the other. The ever-informative 456bereastreet.com have a good summary. But while their conclusion is quite reassuring, it’s two years old – an aeon in web technology – and still vague:

While it’s good to know that sites are not currently being removed without a manual review, that could change in the future. So I would advise anyone making extensive use of CSS techniques that hide text to make sure that it can’t be mistaken for spamming.

How do you make sure? They don’t say.

More recently, SEO Critique took the approach of checking out high-profile designers with close links to Google and seeing if they used image replacement:

Rand Fishkin at SEOmoz does use CSS image replacement on the SEOmoz.org site, albeit sparingly. … I figure that Rand goes to enough conferences and has enough interaction with Googlers like Matt Cutts and Vanessa Fox that if there was a danger of imminent death by penalty he would know and would quickly order the offense removed. Hence, used sparingly and in the strict spirit of If a Blind Person Were Using a Text Reader How Would It Sound? My opinion is that using CSS image replacement is probably okay.

Probably not an issue to get panicked about, then, but one to keep your eye on. I’ll carry on using it judiciously until further notice.