News
rel=me vs sameAs for Brand Identity on Public Sites
July 9, 2025
rel=me vs sameAs for brand identity on public sites is a handshake-versus-claim decision: rel=me (microformats) is a public link meant to be reciprocal for IndieWeb-style verification, while schema.org sameAs is a JSON-LD statement that this Organization or Person is also at those URLs. Use sameAs for search graphs; use rel=me when you want bidirectional proof. RoastMyOpsec does not score rel=me or sameAs as standalone Fs, and neither is a password.
The practical difference
rel=me on an <a> or <link> says “this other profile is me.” Verifiers typically require the remote profile to link back. That is still public HTML, not OAuth. sameAs on Organization is a list of profile URLs in structured data; Google may use it as a hint for a knowledge panel. There is no protocol requirement that the remote site agree.
The OPSEC miss is linking a personal staff Mastodon, a private GitHub org, or a staging dashboard as if it were the brand. humans.txt that repeats the same personal emails is the same class of overshare. Ads.txt and security.txt remain different files with different jobs.
Verified badges on social platforms are their own products. rel=me will not mint a blue check. sameAs will not either.
How to choose based on what you shipped
Brand homepage: Organization sameAs to public profiles the company controls. Footer or about page: rel=me only where you will keep the reverse link. Do not rel=me a personal account as the company. Do not sameAs URLs you do not own.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| rel=me | You want IndieWeb-style bidirectional identity | One-way links and personal accounts on a brand origin | Handshake, still public |
| schema.org sameAs | You want a brand graph for search | Listing profiles you do not control | A claim, not a proof |
| humans.txt credits | Optional culture file with no PII | Personal emails and home addresses | Not an identity protocol |
| security.txt | Researcher intake | Putting Contact only in sameAs | Different well-known job |
When rel=me still wins
rel=me still wins when you maintain reciprocal links for IndieWeb verification. sameAs still wins for Organization JSON-LD. Missing rel=me is healthy on a brochure site. Treating either as a secret identity vault is the mistake.
Common mistakes
The first mistake is sameAs-listing social URLs the brand does not control.
The second mistake is rel=me to a personal staff account from the company origin.
The third mistake is treating missing rel=me as a security finding.
What a URL roast can prove
RoastMyOpsec does not score rel=me, sameAs, JSON-LD, Open Graph, or humans.txt as standalone Fs. The free roast is headers, TLS, cookies, .git/HEAD, .env, package.json signatures, and js-secrets. Identity links are public branding; keep personal accounts and unpublished hosts out of them.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Does sameAs verify that I own the profile?
- No. It is a public claim. rel=me verification looks for a reverse link, which is still not a secret.
- Should the company rel=me employee accounts?
- Usually no. Brand identity is brand profiles. Staff personal accounts are PII-adjacent on a marketing origin.
- Does RoastMyOpsec require rel=me?
- No. Missing rel=me or sameAs is not an F.