Dynamic Number Swapping (Call Tracking) Being Crawled By Google On Website

[JoshuaMackens]

Just wanted to give everyone a heads up.

I checked my client's cache on Google and Google is crawling the dynamic number swap on there. We have it swap when someone visits from Google. I guess Googlebot is coming from Google because sure enough, the number is switched.

You might want to throw all tracking numbers into GMB, not just your GMB tracking number and main phone number.

Also, if anyone knows how to fix that (we use CallRail) I'd love to know how.

 

[JoshuaMackens]

I sent in a support request. I'll try to update the thread with the reply.

 

[mattheffner]

This happened to a client last week. Would love to know what you found out. Not enough spots in GMB for the pool of numbers as I'm using 4-5 so I just deleted them out for now.

 

[Tony Wang]

Ugh, sounds like Google has gotten smarter again, and Callrail (and others) have some work to do. And so do I. Thanks for the heads up.

Just curious, do you swap every occurrence of the # on your website? I usually leave the original # in the footer, and schema matches that, not sure if that'll make a difference.

 

[JoshuaMackens]

Ugh, sounds like Google has gotten smarter again, and Callrail (and others) have some work to do. And so do I. Thanks for the heads up.

Just curious, do you swap every occurrence of the # on your website? I usually leave the original # in the footer, and schema matches that, not sure if that'll make a difference.

It definitely could. I don't know how to exclude swap targets so that the dynamic number insertion ignores the footer.

Do you use Callrail?

 

[Tony Wang]

Yes, I use Callrail. To exclude a swap target, surround part of the number with <span>. For example, instead of (800) 555-1212, type (800) <span>555</span>-1212

 

[Rich Owings]

@Tony Wang Are you saying that will keep Google from crawling the number, but that it will still function properly in Callrail?

 

[JoshuaMackens]

Yes, I use Callrail. To exclude a swap target, surround part of the number with <span>. For example, instead of (800) 555-1212, type (800) <span>555</span>-1212

Excellent! Thanks!

@Tony Wang Are you saying that will keep Google from crawling the number, but that it will still function properly in Callrail?

He's saying it will make sure the number is not swapped by CallRail when Google (or any visitor from Google) crawls. So you'll have at least one number matching what Google expects your phone to be based on NAP on the web and GMB NAP. Does that make sense?

 

[Rich Owings]

Gotcha. Thanks for the clarification.

 

[JoshuaMackens]

So according to CallRail, this is working as intended. They are following the rule Google has about showing Google the same content that the user sees. I'm not sure that should really apply to tracking numbers.

But, again, as far as they are concerned this is working the correct way.

A few things:

1) I wonder if this has caused our clients that do call tracking to drop in Maps at all even though the numbers are in the GMB dashboard now.

2) How can we get around this? I like the idea of keeping the NAP number in the footer or somewhere that's not swapped but then we miss those calls. Maybe the schema markup will save us with the correct number? But then again, maybe it's hurting us because it's not matched? Curious to see what you guys think.

 

[Tony Wang]

Hmm, that explanation from CallRail sounds strange. I recall their literature claiming that the google bot would see the pre-swap #, and that's how they protect your citations/NAP from getting hosed up. Maybe I misundertsood, it was a couple years ago, but I was pretty cautious about implementing all that.

As for missing calls because people use the # in the footer, I think that will be minimal if you don't make the # prominent, and don't make it click-to-call. And there shouldn't be a mis-match, your schema # should be visible on your site.

 

[JoshuaMackens]

I thought I also saw that too which is why I went with CallRail.

With JSON you don't have to have the number visible. So when Google crawls your site they're seeing the correct number in JSON but the incorrect number on the site.

 

[Dan Foland]

Oh man, this is interesting. Thanks for pointing it out. We use CallRail too and I'm seeing cached versions that are including the tracking numbers.

Hopefully we can find a way to prevent this.

 

[Dan Foland]

Now that I'm looking more in to this it appears that the phone numbers are swapping after the cached page is loaded. Meaning tag manager is still firing on the cached page, but Google shouldn't see the dynamic numbers (I believe).

Here's a test you can do that may help.

Do a site search with your tracking numbers e.g. site:yourwebsite.com (123) 456-7890 (or whatever format you use)

If Google is crawling and seeing the dynamic numbers it should be indexed and you should get results back. If Google is not seeing your dynamic numbers no results should appear.

 

[Tony Wang]

@Dan Foland I do a search for those numbers once in a while, just to make sure, but after Joshua's incident, looks like I'm going to have to do it more frequently.

@JoshuaMackens my understanding was that JSON just makes it easier but you should still have data that is consistent with what's actually visible. Otherwise, it would be similar to the old tactic of burying spammy content by hiding it with CSS, no?

 

[JoshuaMackens]

@Dan Foland I do a search for those numbers once in a while, just to make sure, but after Joshua's incident, looks like I'm going to have to do it more frequently.

@JoshuaMackens my understanding was that JSON just makes it easier but you should still have data that is consistent with what's actually visible. Otherwise, it would be similar to the old tactic of burying spammy content by hiding it with CSS, no?

Yes, I definitely agree, you want the data to match. I was just saying that if they're indexing the swapped number, then they aren't matching and that's an issue.

 

[JoshuaMackens]

Now that I'm looking more in to this it appears that the phone numbers are swapping after the cached page is loaded. Meaning tag manager is still firing on the cached page, but Google shouldn't see the dynamic numbers (I believe).

Here's a test you can do that may help.

Do a site search with your tracking numbers e.g. site:yourwebsite.com (123) 456-7890 (or whatever format you use)

If Google is crawling and seeing the dynamic numbers it should be indexed and you should get results back. If Google is not seeing your dynamic numbers no results should appear.

Dang Dan, great catch!

You must be right. Because Google is actually indexing the correct number. I wonder if they can see the incorrect number but understand the dynamic number swap?

Although, I don't use Google Tag Manager. I do a direct insert into code. So it looks like the DNI snippet must fire after the cache is taken? That doesn't make a lot of sense to me though as the swap happens extremely fast, almost instant to the naked eye. Thoughts?

 

[Tony Wang]

Yes, I definitely agree, you want the data to match. I was just saying that if they're indexing the swapped number, then they aren't matching and that's an issue.

Yes, that's why I leave the original number in the footer, so the schema matches what's on the site. It's ok that you also have a tracking # visible, even if it's static; businesses commonly have several phone #'s.

 

[Tony Wang]

Now that I'm looking more in to this it appears that the phone numbers are swapping after the cached page is loaded. Meaning tag manager is still firing on the cached page, but Google shouldn't see the dynamic numbers (I believe).

Here's a test you can do that may help.

Do a site search with your tracking numbers e.g. site:yourwebsite.com (123) 456-7890 (or whatever format you use)

If Google is crawling and seeing the dynamic numbers it should be indexed and you should get results back. If Google is not seeing your dynamic numbers no results should appear.

Dan, just curious how you can tell that GTM fires after the cached page is loaded?

 

[Tiggerito]

Google does not like cloaking, but it is aware of many special cases where showing Google different content is fine. I believe call tracking is one of them.

Google has got better at rendering pages, so maybe some of these call tracking companies are behind the times, and it is letting Google swap in the tracking numbers.

Another way to test is to go into the GSC, do a URL Inspection, then a live test. It will provide you with a thumbnail preview and the rendered html that Googlebot sees. The Mobile Friendly Testing Tool can also be used for that.

I'd also be careful about marking up one number in structured data, and having another one made visible to Googlebot. That's against their Structured Data guidelines.