Well, the SITE NOT RESPONDING status indicates that pings to all of the following failed to respond with a 200 response in a (nearly) timely manner:
https://<our winchill domain name>/Windchill/servlet/WindchillGW/wt.httpgw.HTTPServer/ping
https://<our winchill domain name>/Windchill/servlet/WindchillGW/wtcore/test/dynAnon.jsp
https://<our winchill domain name>/Windchill/servlet/WindchillGW/wtcore/test/staticAnon.html
If you've routed requests for static pages through Tomcat, however, then all of these would be routed to a method server -- and thus one sufficiently unresponsive method server will result in SITE NOT RESPONDING.
Beyond this, my only guess would be that a background method server on a cluster node without any foreground method servers somehow decided to execute the ping -- which it shouldn't. That would either be a bug or a configuration error, but in either case that would be something to confer with technical support about so they can confer with the appropriate development team.
That's certainly worth checking -- though that shouldn't be a problem with 10.1 M040 (the original version noted), as this setting is proper out-of-the-box there. In fact, it looks like it should be proper out-of-the-box in 10.1 F000 and even in 10.0 F000 and R9.1 (M070 at least -- I didn't check all MOR levels). I can only assume the article is addressing cases where this setting was inadvertently changed on site.
See CS49869 for details. Essentially these pings should only come from foreground method servers and need to be disabled from background method servers.
I had the same thing showing up after rehosting the server with a different URL. It also answered all of the pings and testing. I ended up importing in the certificate via the keytools import into the jssecacerts keystore and that fixed it for me.