A site logs your IP, the time and your user agent on every check. Whether it can tell a monitor from a person comes down to three things you can see for yourself.
Does a website know you are monitoring it? It knows a request happened, because a standard web server writes a line for every single check. That line holds your IP address, the time, the address you asked for and your user agent. What it does not hold is a flag saying "monitor". Whether the site works that out comes down to three things: whether your tool names itself in the user agent, whether the requests arrive from one address on a metronome, and whether anything in front of the site is scoring traffic. All three are visible to you before you set a monitor up.
Start with what the server writes down. Apache's log documentation sets out the combined log format, which is what most sites run, and it records nine fields per request.
%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i"
In order: the client IP, two identity fields that are almost always a dash, the time the request arrived, the request line itself, the status code, the size of the response, the referer and the user agent. So the site has your address, your timing and whatever your software said it was. It does not have your name, it does not know why you asked, and one request looks the same whether a person typed the address or a script fetched it.
A single check is effectively invisible. It sits in a log file with thousands of others and nobody reads it. A pattern is a different thing, and a pattern is what a monitor makes.
Three signals, and they are not equally strong.
| Signal | What the site sees | What it proves |
|---|---|---|
| User agent | A string naming the application, operating system and version | Nothing on its own, unless the string names a tool. Anyone can send any string. |
| IP address | One address making repeated requests, and which network it belongs to | A lot. A datacentre address checking one product page every minute is not a shopper. |
| Timing | The gap between requests, to the second | The clearest signal of the three. People do not refresh on an exact 60-second cadence. |
Timing is the one people underestimate. Your user agent can say anything you like, and your address can be a residential one, but a request arriving at 14:03:00, 14:04:00 and 14:05:00 is a machine and everyone knows it. That is also why the answer to "can I avoid this" is mostly about how often you check rather than what you claim to be, which is covered in how often you can check a website without getting blocked.
The address is the second surprise, particularly with hosted tools. Visualping's help centre says that by default it will "crawl the website using a United States (California) IP addresses", and that residential proxies are a business-account feature "which may help bypass bot detection for certain sites". Read on 16 September 2026. If you are watching a UK retailer, a Californian datacentre address checking it all day is the least human thing about the request.
Some do, deliberately. MDN's reference on the User-Agent header describes it as a string that lets servers "identify the application, operating system, vendor, and/or version of the requesting user agent", and gives Googlebot's as the crawler example: `Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)`. Note the URL inside it. That is a bot handing a site owner a page explaining what it is and how to stop it.
RFC 9309, which is the robots exclusion protocol written down as a standard, makes that the rule rather than a courtesy. A crawler's product token "SHOULD be a substring of the identification string that the crawler sends", and crawlers "MUST use case-insensitive matching to find the group that matches the product token". In plain terms: if you want a site to be able to write a robots.txt rule about you, you have to be findable in your own user agent.
Real examples are easy to find. Siteimprove publishes its crawler's user agent and a downloadable list of its IP addresses, naming `SiteimproveBot-Crawler` as the robots.txt token, so customers can let it through their firewall. The older changedetection.com service ships a monitoring tool user agent of `Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://www.changedetection.com/bot.html)`, which Spyglasses' bot directory lists with a robots.txt rule to block it.
So the honest answer for tools in that category is yes, the website knows, because the tool told it. Whether that matters depends on what you are watching. On a corporate site nobody cares. On a shop with a queue for limited stock, an identifiable monitoring user agent is an easy thing to refuse.
On any site behind a network like Cloudflare, the judgement is made before the site's own server ever sees you. Cloudflare's documentation on the bot score sets the range at 1 to 99: a score of 1 means automated, 2 to 29 means likely automated, 30 to 99 means likely human, and 0 means not computed. The inputs are described as request features such as headers, session characteristics and browser signals, plus a JavaScript check aimed at headless browsers.
A low score is a guess about one request rather than a finding about you, which is why an ordinary browser sometimes gets challenged too. And a headless browser, which is what most automated tools drive, is one of the specific things that JavaScript check looks for. If you have ever wondered why a page you can open by hand throws an interstitial at a tool, that is the mechanism, and there is more on it in why a website says verify you are human.
There is a route through the front door, too. Cloudflare runs a verified bots programme with a category for monitoring and operations, and to get in a bot has to identify itself honestly through a cryptographic signature, a published IP list or reverse DNS, respect robots.txt and keep its request rate sensible. The category is worth knowing about: a monitoring bot that identifies itself honestly can be treated as ordinary traffic rather than something to challenge.
For one page at a sane interval, almost certainly not. Nobody is reading their access log looking for you, and the volume is a rounding error next to the search engine crawlers and AI bots already hitting the same URL. What gets a block is volume, and volume is usually accidental: fifty monitors on one shop, a five-second interval on a page that changes twice a year, or a retry loop that fires again the moment it fails.
Read the site's robots.txt first
It is one request and it tells you whether the page is meant to be fetched by software at all.
Match the interval to how fast the page really changes
Seconds for a drop where stock lasts minutes. Daily for a policy page. One interval for everything is how a monitor becomes traffic.
Watch the smallest page that carries the answer
A product JSON or a listing page is cheaper for the site than a full render of the homepage.
Do not hammer a failure
If a check returns a challenge or a 429, backing off is the difference between a bad minute and a blocked address.
Decide whether you want to be identifiable
Announcing yourself gets you allow-listed on some sites and refused on others, so it depends on what you are watching.
It knows a request arrived, because the server logs your IP, the time, the address requested and your user agent for every one of them. Nothing in that record says the request came from a monitor. A site works that out from the pattern: the same address asking for the same page on a fixed interval, or a user agent that names a monitoring tool.
Only if the tool says so or the pattern is obvious. Siteimprove publishes its user agent and its IP list on purpose, and the changedetection.com bot carries its own address in its user agent string. A tool that sends an ordinary browser user agent from a residential address at an irregular interval looks like a visitor.
Not from a plain request. The log has an IP address, not a name. It changes if you are signed in to an account on that site, because then the request carries your session and everything you do is attached to it.
No. robots.txt is a set of instructions for crawlers about what they should fetch, and it has nothing to do with logging. Every request is recorded whether or not the file permits it.
Usually a bot score. Cloudflare's scoring reads headers, session characteristics and browser signals, and runs a JavaScript check aimed at headless browsers, so an automated fetch can land in the likely automated band, 2 to 29, when the same page opens normally by hand.
If you are choosing between tools on this basis, the differences in how they fetch a page are set out in our comparison of website change detection tools.
Watch a page and set your own interval Five free, checked as often as every 60 seconds.