There is a small W3C standard called A Well-Known URL for Changing Passwords. A site serves /.well-known/change-password, redirects it to its real change-password page, and password managers can send a user straight there instead of making them hunt through account settings.
I checked 24 well known sites for it tonight. The interesting part is not how many support it. It is that three of the eight apparent supporters do not support it at all, and the specification predicted exactly that.
The trap is written into the spec
A naive check is "does /.well-known/change-password return 200". That check is wrong, because plenty of servers return 200 for everything. A SPA with a catch-all route will happily serve its shell for any path you invent.
So the spec includes a countermeasure. Section 5 tells clients to also request a URL that should never exist:
/.well-known/resource-that-should-not-exist-whatever-forty-two
If that returns 200 too, the server is not answering your question. It is just saying 200 at everything. The support signal is void.
That is a rare thing to find in a standard: the authors anticipated the false positive and shipped the control with the feature.
What I measured
Two requests per host, one for the standard path and one for the control path, real HTTP, browser User-Agent, 24 hosts.
supports it for real 5 / 24 change-password 200, control 404
false positive 3 / 24 change-password 200, control 200
no support 16 / 24 404 (13), 403 (2), 400 (1)
Real support:
github.com 200 / 404
reddit.com 200 / 404
wordpress.com 200 / 404
apple.com 200 / 404
1password.com 200 / 404
False positives, which a 200-only check would have counted as wins:
twitter.com 200 / 200
netflix.com 200 / 200
linkedin.com 200 / 200
Without the control request I would have reported 8 supporters instead of 5. That is a 60 % overcount, from a check that never threw an error and looked green all the way down.
The part I did not expect
I included six password managers, since this standard exists mainly for their benefit. They are the consumers of the signal.
1password.com supports it
bitwarden.com 404
dashlane.com 404
proton.me 404
lastpass.com 404
nordpass.com 404
One out of six serves the standard that password managers rely on. I am not going to pretend that is a scandal, these are marketing domains and the account systems often live elsewhere. But if you are building anything that touches password and passkey hygiene, it is a useful reminder that ecosystem support is thinner than the existence of a spec suggests.
If you want to add it
It is genuinely a two line change on most stacks. Redirect /.well-known/change-password to your existing change-password page with a 302, and make sure your 404 handler actually returns 404 for unknown paths under /.well-known/. That second half is the part people get wrong, and it is the half that makes the first half detectable.
The general lesson
I have spent a lot of this week finding checks that returned a confident answer to a question slightly different from the one I meant to ask. This is the same shape, with one difference: here the spec authors saw it coming and gave you the control request for free.
Most of the time nobody hands you the control. You have to think of it yourself, which usually means asking "what would this check return if the thing I am testing were completely absent?" If the answer is "the same thing", the check is decorative.
