Site outgoing traffic is often limited, especially if it is not a big portal or mall. Thus it wouldn't be wise to select 'heavy', big HTML page to check, it could, under certain circumstances, drain the site of its traffic quota sooner. An ideal solution would be to have specially crafted pages, light in size and causing as little site load as possible (e.g. with few or none database requests and the like).
Another point is sending appropriate headers. In modern Web applications a number of checks may be made to prevent automated access to the system - a common means to ward off such scripts as email harvesters, automated reply bots and the like. Thus, not only sensible information should be passed in headers of the request, but also one should make sure that the POST request is done, if necessary, after the GET request is sent first, and pass whatever cookies are set.
Finally, I would be careful not to send any type of monitoring requests too often. That could not only load site too much, but could also trigger a spam or DoS alert on the site. So, idea is to verify the site presence with lighter tools, such as PING, wherever those are available, and only occasionally send the GET or POST requests.
A polling interval of 60 seconds could be enough for any real-life task, and if necessary, pinging could be performed several times a minute, and only after that a real HTTP request would be sent.
The resume is: to check the site state, one should choose lightweight page(s), perform occasional polling/requesting pages, setting headers as expected and testing the page contents, without an assumption that the error code would be really returned if an error occurs.
