Plugin Author
Josh
(@oojosh)
Hi baartolomeo,
I checked your page’s source and the tel: links are being protected correctly. What you’re seeing is a View Source vs. Inspect difference.
In your page’s raw HTML source, the phone links are HTML-entity-encoded, for example: href=”tel:+48601333491″ The plain tel: number doesn’t appear anywhere in the source, a bot scanning the raw HTML for tel: won’t find it.
The readable href=”tel:+48…” you saw comes from the browser’s Inspect/DevTools, which shows the decoded live DOM: the browser automatically decodes those &#…; entities and runs the small script that fills in the number. If you open the page and use View Source instead of Inspect, you’ll see the encoded form.
Hallo Josh,
I looked through the plain page’s source and you’re right – the values are encoded.
But I was just thinking – if encoding this way is not a real problem for DevTools – is it hard enough for scanning bots? I am not the expert of web scrapping and I don’t really know what tools are used in major to do it, but it should have been fairly easy to interpret the encoded strings correctly if anybody cares to do it. I am just curious 😉
Plugin Author
Josh
(@oojosh)
Hi baartolomeo,
You’re right, entity encoding isn’t unbreakable. A bot that decodes the entities or runs JavaScript can still get the number, and nothing can fully prevent that, since a clickable tel: link has to expose a dialable number somewhere.
But it works against the bots that matter: the vast majority just scan raw HTML for patterns like tel: or @, and the encoded source contains none of those as literal text, so they match nothing and move on. It’s deterrence against drive-by scrapers, not a lock against someone deliberately targeting your site.
Hi Josh,
many thanks for your explanation.
Cheers.
