Determining the cause of strange localised traffic spikes that don't appear to be from human visitors requires patience and detective work, but the basic steps are to:
Find out where it's coming from using the tools available to you (see below).
Determine if it's dangerous or not by analysing the sources of the request, the frequency, the request headers themselves, and the effect on your network and server(s).
Decide whether to block it in Google Analytics alone just to prevent it from appearing in your stats (using a Google Analytics filter), to block it at the server to prevent it ever reaching your site in future (using a firewall or a service such as Cloudflare), or to ignore it altogether.
I won't detail the security implications here because you seem more concerned about the effect it's having on your analytics data. Here are some observations about this particular case, with some pointers to determine the possible source and filter out unwanted traffic in Google Analytics:
It's probably not Pingdom
The Google Analytics spikes are unlikely to be visits from Pingdom for two reasons:
Pingdom don't currently have servers in Edinburgh. They list all of their Probe servers with the IP addresse and location on a page in your control panel (the link named "Probe servers" in the bottom right of all Pingdom admin pages when you're logged in). The only two listed in the UK right now are in Manchester and London.
But you don't have to take my word for it. If the spikes are ongoing and you want to confirm that Pingdom is not the cause of the sudden visits and bounce rate spikes, you could:
Pause the Pingdom requests to your site and see if the hits from those areas disappear. (I suspect it won't make a difference.)
— or —
Set up a page at
example.com/pingdom/any-url-you-like, point your Pingdom requests to that page instead of your homepage, and exclude the
/pingdom/ subdirectory from your Google Analytics results by (a) removing the Analytics tracking code on that page, or (b) using a filter to exclude the page in Google Analytics if you can't remove the tracking code on a per-page basis (e.g. if you're using a CMS that includes the code on every page, and you don't have enough access to alter this behaviour).
How to filter requests with Google Analytics
Log in to Google Analytics and click the "Admin" link (top right, next to "Help")
Click the domain name or site name for the profile you want to filter. (e.g.
Click the "filters" tab.
Click "+ New Filter".
Give the filter a name and leave "Predefined filter" selected.
Select "Exclude... traffic to the subdirectories... that are equal to" from the dropdown boxes.
/pingdom/ into the Subdirectory field, and leave "Case Sensitive" set to "No".
This should be the result when you're done:
Save these settings, then repoint your Pingdom checks to
example.com/pingdom/any-page-or-url-that-exists, and Google Analytics will now be filtering visits to that URL. (You'll still get basic server uptime reports this way, even though Pingdom's no longer pointing to your homepage.)
If it's not Pingdom, where are those hits coming from?
You can try to find out in a number of ways:
1. Look at what network is sending you the most bounced traffic. To do that with Google Analytics, look at the Standard Reporting section for your site, then choose Audience > Technology > Network from the left-hand side. Finally, with the pie chart mode selected (the default), choose "Contribution to total... Bounces" from the drop down on the right:
You'll see a list of ISPs or network providers whose users have contributed to your bounce rate. Sometimes this will be a small, specific ISP that you can trace to one area or business. Armed with the name of the network provider sending you the bouncing traffic, you could choose to filter that particular network from Google Analytics as described above, but filtering by network instead of by subdomain.
Other times, the top ISP listed will be a large domestic provider who may have millions of customers, and you'll be none the wiser. At that point, Google Analytics can't help you drill down and determine which of that provider's customers are sending repeated bounced traffic (because Analytics no longer includes IP address info or other identifying data). To get that sort of data, you can either use another stats provider who does log IP addresses (like Clicky), or you can analyse your server logs, which also records access by IP address:
2. Examine your web server access logs to explore visits from known crawlers and look for repeated access from the same IP address. A web-based stats tool such as AWStats can help you with this. It's quite popular among certain web hosts and they may already have installed it for you.
Here's some sample output from AWStats. The two relevant sections for you are "Hosts" and "Robots/Spider visitors".
Got an IP address? Find out who's using it.
If you do manage to obtain an IP address from the Hosts section in AWStats or elsewhere, you can do a reverse IP lookup to determine who might be using it.
The reverse IP lookup will often give you the name of a hosting provider who you could report abuse to if you believe that the requests are malicious. Or it may give you the name of a domestic ISP who's customer is using scripted automation in an attempt to exploit your website. You can normally send abuse reports to
example.com is the name of the hosting provider or ISP. And, sometimes, it will offer up the name of a specific company who you can contact for more information.