Detecting a WordPress URL without doing a full HTTP GET?

I’m trying to write a oneboxing routine that gives WordPress blog entries special treatment. So given a simple, unadorned URL in content, such as

http://blog.stackoverflow.com/2011/03/a-new-name-for-stack-overflow-with-surprise-ending/

How would I detect that this is a WordPress installation, ideally without doing a full HTTP GET on every URL I see?

There are certainly common conventions for WordPress URLs that we could start with, which eliminates at least some URLs from contention. In this case it is …

http://example.com/year/month/slug-goes-here

But that isn’t a universal constant either.

I tried looking at the headers of that URL using HTTP HEAD, and I see:

Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:18340
Content-Type:text/html; charset=UTF-8
Date:Thu, 07 Jun 2012 07:07:38 GMT
Keep-Alive:timeout=15, max=100
Server:Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Vary:Cookie,Accept-Encoding
WP-Super-Cache:Served legacy cache file
X-Pingback:http://blog.stackoverflow.com/xmlrpc.php
X-Powered-By:PHP/5.2.6-2ubuntu4.2

I don’t think relying on the presence of WP-Super-Cache would be particularly reliable, and that’s the only thing I see in the headers that would help, so maybe there are zero common HTTP headers in a WordPress install?

From my experience and quick code search there are no deliberate ways WP identifies itself in headers. However there are some that seem distinct enough and not likely to be customized.

HEAD to /wp-login.php will contain following for .org install:

 Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

And for .com:

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/; domain=.wordpress.com

Cookie name is customizable by defining TEST_COOKIE constant, but WP Cookie check string is hardcoded in core, as well as set_cookie() call for this in the file’s source.

For locating wp-login.php there are some URL shortcuts (implemented in wp_redirect_admin_locations() since WP 3.4 (see ticket #19607 ):

/login on site’s root does 302 redirect to wp-login.php, wherever it is.

So the only scenario that cannot be reliably detected if WP is installed in and confined to subdirectory, without being used to manage site’s root at all.