Many services allow verification of a personal site by one of the following mechanisms:

adding a meta tag to the head of the page
adding a specific .txt file at a well-known URL
(eg Keybase supports this)

I know the objections to parsing generic HTML pages – boiling down to (a) fragile parsing and (b) what about user generated content. But I don't think either of those issue apply here.

Specifically, I am proposing we implement one or both of the following mechanisms:

<link rel="pgpkey" ...> in the HTML head.
This proves ownership of a specific page at a specific URL. If it's at the root of the domain, that could be considered to prove ownership of the whole site.
I don't think the objections to HTML parsing apply because (a) it's a well-defined link rel value in the head, not an arbitrary DOM path which would be subject to fragile parsing, and (b) if it's in the head, the potential for user-generated content (eg comments) messing with it isn't an issue.
The rel="pgpkey" value is already used for RelMeAuth, amongst others.
The link href points to an ASCII-armoured key, so the same implementation would solve Git forges and Facebook and Keybase.
Alternatively we could use a custom meta tag containing the fingerprint. I prefer the link version though since it's already used for other things.
A text file at a well-known URL.
Keybase uses this method. Unfortunately they use a file in the root directory of the site, instead of in .well-known, but it works the same way. The file could contain the fingerprint or maybe even the ASCII-armoured key, or it could just have the fingerprint as the filename.

Either of the above methods would mean we could support Neocities, for instance, without needing a special implementation just for that site based on their API.