homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Google / Google SEO News and Discussion
Forum Library, Charter, Moderators: Robert Charlton & aakk9999 & brotherhood of lan & goodroi

Google SEO News and Discussion Forum

Does tagging URLs with reference parameters affect SEO?

 11:24 am on Jan 21, 2013 (gmt 0)

So we have been ranking #1 on Google for a page (say /page1.html ). Since this page is linked more than once on the Homepage and other high traffic pages, we found it logical to add a reference parameter at the end of the URL.

So, the anchor link to the page from the sidebar became /page1.html?ref=sidebar, the one on the navigation became /page1.html?ref=nav,etc. Now during the same period, the average ranking of the page on Google has dropped from around 1.1 on the Webmastertools to around 2.5.

I'm not sure if this could be one of the reasons. The drop in the SERPs has not been drastic, so I am not able to absolutely confirm the specific change that has caused the drop, but I would be interested to learn if this reference tagging could have an effect on the ranking.



 3:11 pm on Jan 21, 2013 (gmt 0)

Yes, it could be one of the reasons. For both pagerank and anchor text purposes, Google treats page.html and page.html#anchor as separate urls.

This appears to be because the support linking into sections of documents. We've seen this in the SERPs for wikipedia, for example. On the other hand, it seems like an algorithm weakness that can still be exploited by technical SEO, and may in some cases like this cause unintended consequences.


 4:20 pm on Jan 21, 2013 (gmt 0)

Google treats page.html and page.html#anchor

This is incorrect. Google treats the above as the same URL, that is, there will be no duplicate content issue.

There have been some tests performed with a page that has two outbound links to the same URL with the difference being named anchor, and these tests seem to show that in that case the same link passed two different anchors to the target page, but this is nothing to do with "Google treating it as separate URLs".


 4:41 pm on Jan 21, 2013 (gmt 0)

Its not just anchor text that is affected when the link has a named anchor. It is also pagerank. The testing I performed indicated that two links to page.html on the same page pass only as much page rank as one link. Links to page.html and page.html#anchor both pass pagerank. When this happens, its unclear to me where this pagerank "goes" for the link with anchor on it. It may only apply to a section of the page.


 4:45 pm on Jan 21, 2013 (gmt 0)

But Google (and all of the other search engines, for that matter) will treat /page1.html?ref=nav and /page1.html?ref=sidebar as separate URLs and you should take steps to prevent this from causing canonicalization issues or to repair any that have already occurred. The simplest way is to use the rel="canonical" tag.


 4:46 pm on Jan 21, 2013 (gmt 0)

I understand it with the page.html#anchor kind of linking. However in my case, it is page.html?ref=id kind of a linking. Does that affect the SEO as well?


 4:51 pm on Jan 21, 2013 (gmt 0)

Oh yes. Parameters are even worse than anchors in this regard. Implementing canonical tags would be the way to go in that case.


 8:15 pm on Jan 21, 2013 (gmt 0)

As above, you need
rel="canonical" pointing to the URL version without any parameters.

 3:07 am on Jan 22, 2013 (gmt 0)

Since this page is linked more than once on the Homepage and other high traffic pages, we found it logical to add a reference parameter at the end of the URL.

Logic is a means, not an end. (Everyone gets this wrong.) What purpose were you trying to achieve?

Along with the "rel=canonical", you can go to GWT and tell them to disregard the "ref" parameter.


 3:52 am on Jan 22, 2013 (gmt 0)

Thanks all for the response. Shall set up the canonical as well as the Webmaster configuration (just discovered this recently via another discussion).

What purpose were you trying to achieve?

It's easy to check out on page traffic from various sources when using the ref parameter. (We just have to go to the Site content -> All Pages and filter the page traffic by the specific paramters to view traffic from these particular links.


 7:31 am on Jan 22, 2013 (gmt 0)

There's no referer setting? Seems redundant that you would have to put the referer into the URL, which seems to be what you're doing :(

:: detour to piwik to look into parallels ::


 7:37 am on Jan 22, 2013 (gmt 0)

No, as I have mentioned in the opening post, we have multiple links from the same page to the link in question. So to understand which of the 3 links from the homepage is bringing us traffic, we have to be adding a parameter to identify the 3 links separately.


 7:39 am on Jan 22, 2013 (gmt 0)

Totally with lucy24 on this...

Why not just use PHP (or whatever) to grab the referrer when a visitor lands and not worry about putting it in the URL? The only way you shouldn't get it is if the visitor has set their browser to not send it (unlikely) or they're coming from a secure site.

If you're putting them in first (meaning the referring site links to something like example.com/somepage.ext?ref=WeReferredSomeone), then personally, I'd seriously considering running them through a PHP redirect that strips the parameter out of the URL and stores the info in a DB and cookie ... Please, keep in mind, I am a bit crazy, so it might not be the 'absolute best solution for search engines', because you lose a % of PageRank through each redirect (Oh, No!), but sometimes I try to not care about them so much and don't want a tacky looking url for visitors, which is what you end up with, in my opinion, if you don't strip the query string and store the info in a cookie 'on the way to the page' via PHP or some other scripting lang.


 7:46 am on Jan 22, 2013 (gmt 0)

Oh, if I'm reading your post you were making at the same time I was making mine right and the links are on your site, then I'd definitely run them through a redirect, store the info and strip the query string before the visitor landed on the destination page ... No question for me, there's no way I'd go with 'ugly URLs' for onsite visitor tracking ... Check out what happens here when you click a link that's posted rather than hard coded into the HTML (except links to posts) ... They all run through a redirect.

Here's an example...

Hover over it and see where it actually goes.


 10:05 am on Jan 22, 2013 (gmt 0)

Just to be clear here, the OP has a link to "/page" from the top-nav of the home page, from the left nav of the home page and from the footer of the home page. In order to see which link on the home page the user has clicked, the OP has added a query string paramter to the URL in the href.

This is a duplicate content situation, so you will need the rel="canonical" tag on the target page. You must also have at least one link that points to that canonical URL. That is, you must not have a situation where every link pointing to the sub-page has parameters.

You can also instruct Google to ignore the ?ref= parameter within WMT. This doesn't help with other search engines.


 1:59 pm on Jan 22, 2013 (gmt 0)

If you are tracking visits via Google Analytics, there is a special feaure that you can set up to track events. So if you have 3 outbound links to the same URL from the same page, you can label each of these with a different label and use different category to mark sending page and use different action for target page.

For example, category could be 'home_page' and label can be 'footer' and action can be 'target_page_name'. This would then show in GA where you can then see links clicked grouped by any of these three values.

This way you do not need query string in URL for tracking purpose. Note that this works for internal linking only.


 2:38 pm on Jan 22, 2013 (gmt 0)

While "most of the time" Google may be able to figure out that /page.html and /page.html?ref=sidebar are, in fact, the same page, why on earth would you even want them to have to? Why even take the chance? And Google isn't the only engine out there. While Google may be able to figure it out, other engines might not.

I constantly hear people here say, "Ah... It's not an issue. Google can figure it out and won't treat as duplicate." Google "tries" to determine which of the URLs is the canonical and give it credit for all of the other non-canonical pages' links, but they don't always get it right. Be explicit. Using a single canonical URL for all of your links on your site is so easy. With the exception of huge ecomm sites where there are often needs for query string parameters for sorts, filters, categorys, sub-categories, etc. using a single canonical URL on your site for every page is usually a no brainer.

Query string parameters in general are a bad idea because each value of a parameter as well as the order of the parameters create new URLs, even though ALL such URLs may render the same content. The same page could have literally millions of URLs in some cases when you consider all of the combinations and permutations parameters and values.

Using query string parameters for tracking, especially for internal tracking of where people on clicking on your own site, is just ludicrous. 99% of those that implement such internal tracking "might" look at it once, and then rarely if ever look at the results again.

If you insist on trying to figure out which link to PageX people are clicking on to arrive at the page (the one in the top nav or the left nav or the footer, etc.) there are other ways. For example, all of those links can have the canonical URL as the HREF attribute value and you can use the ONCLICK attribute to trigger some JavaScript to tag an event in your analytics specifying which particular link was clicked.

The really bad thing about exposing non-canonical links like /page.html?ref=sidebar on your own site is that the way most people create links to your site is by browsing to a page on your site, copying the URL from the browser address bar, and pasting it into a link. Depending on which link they clicked on (top nav, left nav, footer, etc) to arrive at a page to which they want to link, they will get a different URL. So you're perpetuating having other sites link to your URLs with a variety of non-canonical URLs.


 3:03 pm on Jan 22, 2013 (gmt 0)

That last point is the real kicker.


 12:32 am on Jan 23, 2013 (gmt 0)

Follow-up question:

If you have something like

<a id = "firstname" href = "otherpage">Something</a>
<a id = "secondname" href = "otherpage">Something-Else</a>

on the same page, will your analytics program identify those as different referers? (The server of course won't, but now we're in analytics.) Or is the referer determined only by the contents of the address bar?


 4:33 am on Jan 23, 2013 (gmt 0)

Not unless you use the ONCLICK attribute to trigger some JavaScript to tag an event in your analytics specifying which particular link was clicked.

By the way, use
href="/otherpage" with a leading slash, not href = "otherpage", if you can.

 10:47 am on Jan 23, 2013 (gmt 0)

But these ref parameters are quite often used by many sites including Amazon. A proper study on how they do it will help.


 11:14 am on Jan 23, 2013 (gmt 0)

Big sites often employ some of the worst techniques there are. Don't mimic them or set the bar down at their level unless you're sure the technical implementation is OK.


 3:09 pm on Jan 23, 2013 (gmt 0)

I don't know about others, but Amazon does it perfectly. They do manage to get the right URLs indexed, irrespective of what a human visitor sees or clicks thro. (which is never the same as what the search engines index). I am not arguing that they are doing it right or wrong, but they are definitely in control of everything. So IMHO a study of how they are doing it will throw a lot of insights.

Global Options:
 top home search open messages active posts  

Home / Forums Index / Google / Google SEO News and Discussion
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved