Blogging & Open Web

rel="me" for a Personal Website - Connect Profiles Without Calling It Proof

Written by Adam Muiz 28 Oct 2026 Updated: 28 Oct 2026 9 min read

A personal website may link to a code forge, a social profile, and a publishing account, but an ordinary hyperlink says little beyond “this page points there.” How can software tell that a link is meant to connect two representations of the same author rather than recommend an unrelated page?

The small HTML token rel="me" offers one answer. It gives a link an identity-related meaning that people and software can inspect. Some services can also look for a link back and treat the pair as evidence that the same operator controls both endpoints. That is useful, but the word “verification” needs restraint: a reciprocal link is not a passport, a cryptographic signature, or a permanent guarantee about the person behind either account.

The more accurate question is not “Does rel="me" prove who someone is?” It is “What relationship is being asserted, what did a particular consumer check, and what could have changed since then?”

A link can say more than “go there”

RFC 8288 describes a Web link as a typed connection with a context, a relation type, a target, and optional target attributes. In an HTML link from a homepage to a profile, the homepage is the context, the profile URL is the target, and me names the relationship.

This distinction is easy to miss because a browser still renders a normal clickable link. The extra semantics are mostly for software and for people reading the markup:

<a href="https://social.example/@mira" rel="me">
  Mira on the social web
</a>

The IANA Link Relations registry lists me with the description “Links to a resource about the author of the link's context.” The wording matters. The page containing the link makes a claim about how its author relates to the target. The token does not make every fact on the target true, and it does not tell a consumer how much trust to assign to the claim.

The rel attribute is a space-separated set of tokens, so an external link may carry several independent meanings:

<a href="https://social.example/@mira"
   rel="me noopener"
   target="_blank">Mira on the social web</a>

Here, me describes the identity relationship. noopener concerns the browsing context opened by target="_blank". One does not replace the other. Adding nofollow, noopener, or another token also does not secretly cancel me; each recognized token has its own semantics.

One link is an assertion, not independent confirmation

Anyone who can edit a page can add a link claiming a relationship with any target. A page controlled by an impersonator could point to a well-known profile and write rel="me". The target has not agreed merely because the source says so.

A consumer can ask for a second signal: does the target also point back in the expected way? The resulting loop is often called reciprocal or bidirectional verification. If a personal site links to a social profile and that social profile links back to the site, the arrangement is evidence that someone could edit both endpoints when the check succeeded.

That conclusion is narrower than “these pages reveal the person's real identity.” It does not establish a legal name, prove that only one human uses the accounts, or guarantee that control will remain unchanged. It is closer to finding two doors whose occupants have placed matching directions to each other. The signs are useful, but they say something about coordinated control, not everything about the occupants.

Reciprocity is also a consumer policy, not an extra universal rule hidden inside the me relation. RFC 8288's security considerations warn applications to consider the risks of automatically following or trusting collected links. Different consumers can fetch different pages, follow different redirect rules, impose different limits, or decline to perform a verification check at all.

Mastodon is one concrete consumer

Mastodon's profile documentation provides a useful implementation example. When an HTTPS link is placed in profile metadata, Mastodon can fetch that page and look for an <a> or <link> element whose rel contains me and whose href matches the Mastodon profile URL. If the check succeeds, Mastodon can mark that profile link as verified.

The backlink may be a visible link in the page body, as in the earlier examples. Mastodon also documents a metadata form in the document head:

<head>
  <link rel="me" href="https://social.example/@mira">
</head>

The official documentation says the qualifying link must be present in the HTML response; Mastodon does not execute JavaScript to discover it. That detail explains a common failure mode: a link inserted only after a client-side application runs may be visible to a visitor but absent from the HTML that the verifier examines.

This is specifically Mastodon's documented behavior, not a promise about every social network or every version of every server. Even within one ecosystem, software can cache results, change validation rules, or expose a different user interface. The durable part is the typed link. The verification badge is a product's interpretation of evidence it chose to inspect.

A cautious setup workflow

1. Choose a page that represents the author

A personal homepage or a dedicated author page is a sensible context because the page itself represents the person or entity making the claim. Adding rel="me" to every outbound link in every article would blur that meaning. The IndieWeb community guidance suggests using it on pages that represent the same person or entity, while an author relationship may be more appropriate when an ordinary article points to its writer.

2. Link to the canonical profile URL

Use the exact HTTPS profile URL expected by the consumer. Seemingly minor differences can matter to an implementation: a redirected short URL, a different hostname, or an alternate profile route may not compare equal after the consumer applies its rules. Avoid treating trial and error as a specification; consult the target service's current documentation.

3. Put the relationship in delivered HTML

Use a normal visible link when it helps readers discover the profile. A head-level <link> can be suitable when the consumer supports it, but it should not be used as an excuse to hide useful navigation. In either form, inspect the origin response rather than only the hydrated browser DOM:

curl -s https://example.com/ | grep -E 'rel="[^"]*me|href="https://social\.example/@mira"'

This command is only an inspection aid. A matching line does not prove that the HTML is valid, that the profile links back, or that a specific consumer accepts the page. It also assumes a simple quoting style and can miss equivalent markup. An HTML parser or the service's own verifier is more authoritative for its implementation.

4. Add the return link where the service expects it

For a reciprocal check, the external profile must point back to the personal site. Whether the service emits rel="me" on that return link, and what field must contain it, is platform-specific. A plain text mention of the domain may not create the typed link a verifier needs.

5. Trigger and inspect the check

Save or refresh the profile as the service instructs, then inspect both ends. Confirm that redirects settle on the intended URLs, TLS is valid, the page is publicly reachable, and the relevant markup appears without authentication or JavaScript. A badge can be a convenient result, but the inspectable links remain the underlying evidence.

What can make yesterday's verification misleading?

Control on the Web changes. A domain can expire or be transferred. A social account can be renamed, deleted, compromised, or reassigned. A CMS edit can remove the backlink while a platform continues to display a cached result. A reverse proxy can serve different HTML to different clients. None of these possibilities makes reciprocal links useless; they make the time and method of the check important.

There is also a difference between controlling an endpoint and endorsing everything reachable from it. A verified connection to a profile does not certify every post, attached file, or linked account. If a high-stakes decision depends on identity, use evidence appropriate to that decision rather than promoting a convenient Web signal into a stronger credential.

Maintenance should therefore be ordinary and explicit:

remove or update links when an account moves;
keep domain registration and account recovery secure;
recheck important connections after a migration or theme change;
treat unexpected changes as a reason to investigate, not as proof of malice;
avoid displaying a permanent local “verified” label unless the site also defines how and when it revalidates the claim.

Do not confuse a relationship with a protocol

rel="me" is a link relation. By itself, it does not implement login, exchange ActivityPub messages, recover an account, or establish a global identity record. Other systems may use the relation as one input to a larger process, but their additional rules do the additional work.

The nearby author relation is not a spelling variant of me, either. IANA registers both separately. A link from an article to its author answers “who authored this context?” A me link on a personal page connects that author's representation to another resource about the same author. A site can need both in different places.

A modest claim is the useful claim

rel="me" is valuable precisely because it is small. It lets a page state a machine-readable relationship using ordinary HTML. A consumer may combine that statement with a return link and obtain evidence of coordinated control over two endpoints. The mechanism remains inspectable and does not require every personal site to join one central identity provider.

Its limit is equally important: the link says less than a universal identity system, and a reciprocal check proves less than a legal identity document. Used with that boundary intact, it can connect a personal domain to scattered profiles without pretending that one HTML attribute has solved identity on the Web.