Call Tracking Numbers & their Effect on Google Places/LSO Ranking

Daryl Marritt
For the past year, I have been asking many LSO (Local Search Optimization) experts like 'Greg Gifford' whether call tracking numbers in my website header will effect my LSO ranking, most importantly on Google Places. To this day, I have yet to receive a definitive answer and am uncomfortable making a change. Here's my conundrum, I currently rank #1 in my local area with my real local phone number listed in my site header, matching the number in my Google Places profile and other online citation directories. The problem is, I don't get enough recorded call traffic to do proper phone training with my team and would like to replace my website number with a call tracking number. Additionally, the tracked conversations would be sent directly into my CRM as a lead. I have tried CT #'s in the past with mixed results due to Canada's lovely long-distance zoning. Some 'local' tracking numbers still activate long-distance charges, even if you live across the street from our dealership and on the flip side some guests are weary of calling an '800'/toll-free number. What should I do? Can someone give me a definitive answer on call-tracking numbers listed on the site header? If you have a dynamic call tracking number, does Google see your local number in the code when it crawls your site? Should I just list a toll-free option below my local number and just track those calls?
Dan Ferguson
List the call tracking # as a graphic in the header, and leave your local # (and address and name) in schema that Google will easily understand. When in doubt about the formatting, refer to a Schema generator such as Schema-Creator.org
Lance Weatherby
​This is a bit of a long answer but I believe it answers your question. Name-Address-Phone (NAP) consistency is a significant ranking factor for local businesses. Because of this, businesses need to display a consistent phone number on their website and local directories (Google Local, Yelp, Facebook, etc.) That's part of the reason that dynamic number insertation) DNI exists in the first place -- show the right number to visitors while leaving NAP consistency alone (the larger reason is to display different phone numbers for each marketing campaign).​ In the olden days, Google didn't really run JavaScript at all, so putting DNI in JavaScript was enough to keep it from being indexed by the search engines. Over the past several years, Google has gotten more and more comprehensive about indexing JavaScript. Today, Google renders pages using nearly complete JavaScript on both desktop and mobile -- allowing it to view and index websites with heavy client-side rendering and single-page-app experiences. Google also frowns on "cloaking": showing different content to users and search spiders in an effort to mislead the search engine. Google defines cloaking as (via https://support.google.com/analytics/answer/2576845?hl=en). To quote Google: "Cloaking is the practice of presenting a version of a web page to search engines that is different from the version presented to users, with the intention of deceiving the search engines and affecting the page's ranking in the search index." But Google goes on to clarify that testing and optimization is encouraged. Again quoting Google: "Google does not view the ethical use of testing tools such as Content Experiments to constitute cloaking. We encourage constructive testing. Optimizing your web pages benefits advertisers as well as users by increasing conversions and by presenting the most desired information more efficiently.​" So how did CallRail do to address this? We simply used robots.txt to tell the Googlebot "hey, don't look at our swap.js file". Googlebot, being a good and honest robot, obeyed. Since then, Google began notifying webmasters when it was blocked from accessing JavaScript, and warning that it would have a detrimental effect on search rankings. So we removed the robots.txt restriction. For keyword-level tracking, our call tracking system it smart enough to tell Googlebot "don't actually insert a tracking number", and likewise, we don't track visits from Googlebot. Doing so would pollute data, significantly increase need for pooled phone numbers, and increase costs. So that solution still works well. For source-level tracking, most sources are configured to swap based on something in the referring URL or the landing page -- a referrer from a paid or organic search result, or a parameter found in a landing page URL. Googlebot doesn't provide any of these, so the swap typically doesn't happen. The exception is source trackers configured to display to "direct" or "all" visitors. Googlebot does fit that description, and now that we're serving our JavaScript to Googlebot, it's rendering pages with tracking phone numbers. To deal with this we gave Googlebot as much of a "real user" experience as possible. Googlebot sees the call tracking code for such trackers, runs them, and swaps a phone number if appropriate. With one key exception: it to swaps in the same phone number (the swap target) as it's replacing, so that it doesn't actually change the page and interfere with NAP. This addresses the NAP consistency issues that can potentially be introduced by call tracking in a way that is consistent with Google's own guidelines. So we think that CallRail call tracking will enable you to use dynamic call tracking while presenting Google with a consistent number at the same time. It's the best of both worlds.

Featured Masters

No members found

Other Marketing Solutions Products

0%  Recommended Recom'd 0 Ratings
Company: DealerSuccess
0%  Recommended Recom'd 0 Ratings
Company: DealerSuccess
0%  Recommended Recom'd 0 Ratings
Company: Outsell
0%  Recommended Recom'd 0 Ratings

 Rate a Vendor Give feedback in three quick steps

Select a Vendor & Product
Can’t find what you're looking for?
Add a Vendor  or  Add a Product
  •  
  •  
  •