The rel=me Tag: Two Characters That Verify Your Entire Identity Network
· 8 min read
There is a two-character HTML attribute that most web developers have never used and most business owners have never heard of. It sits quietly in link tags, doing almost nothing visible to the human eye, but doing something significant to the machines that verify identity across the web.
It's rel="me".
If you're serious about entity verification, about making your identity network machine-readable and trustworthy, this attribute is not optional. It's foundational.
What rel=me Actually Does
rel="me" is a relationship attribute. When you add it to a hyperlink, you're asserting that the destination URL represents the same person or entity as the current page.
A basic implementation looks like this:
<a href="https://linkedin.com/in/hibranwar" rel="me">LinkedIn</a>
<a href="https://orcid.org/0000-0000-0000-0000" rel="me">ORCID</a>
<a href="https://github.com/hibranwar" rel="me">GitHub</a>
Or in a <link> tag in your <head>, invisible to visitors but readable by machines:
<link rel="me" href="https://linkedin.com/in/hibranwar">
<link rel="me" href="https://mastodon.social/@hibranwar">
The declaration is simple. The effect, when combined with reciprocal links from those external profiles back to your website, creates something important: a verifiable chain.
The Reciprocity Requirement
This is where most people stop short and wonder why it isn't working.
rel="me" works through mutual confirmation. Your website links to your LinkedIn with rel="me". Your LinkedIn profile URL field links back to your website. When a verification system checks the chain, it finds: website claims to be the same entity as this LinkedIn, and LinkedIn's URL points back to the same website. Confirmed.
One direction alone proves nothing. Anyone can claim to be associated with any profile. The verification comes from both sides of the link pointing to each other.
This is the same logic that email verification uses. You can claim any email address you want, but until you confirm from inside that email account, the claim is unverified. rel="me" creates the same kind of bilateral confirmation for web identities.
Why This Matters for AI Search Specifically
I've been building entity infrastructure for three companies (Witanabe, Arsindo, Hibrkraft) and my own professional identity, and I've watched how different signals compound over time.
The rel="me" network contributes to something specific: what the IndieWeb community calls a "web of trust." When AI systems and search engines evaluate whether an entity is verifiable, they look for exactly this pattern. Multiple authoritative sources, all confirming each other's claim to the same identity.
Google's People Also Search For, the Knowledge Panel trigger, and increasingly the sources that AI agents cite, all depend on this kind of identity coherence. A website that floats disconnected from any verified external profiles is a claim without corroboration. A website that participates in a rel="me" web of mutual confirmation is a verified node.
The difference between being cited and not being cited by AI search often comes down to whether the identity network is verifiable. Not how good the content is. Not how much it's been shared. Whether it's verifiable.
The IndieWeb Foundation
rel="me" was formalized by the IndieWeb movement, a community of developers and writers who believe in owning your digital identity on your own domain rather than surrendering it to social media platforms.
The concept, called "RelMeAuth" in its more complete form, enables distributed identity verification. Instead of needing a single authority (like Google or Facebook) to verify who you are, you can build a self-sovereign identity verification network across multiple platforms, with your own domain at the center.
This matters enormously for the kind of long-term entity building I'm doing. I don't want my professional identity to live primarily on LinkedIn, where a policy change can alter my visibility overnight. I want hibranwar.com to be the canonical hub, with every external profile as a spoke that confirms and extends the hub's identity. rel="me" is the mechanism that makes the hub-and-spoke structure verifiable.
Implementation for Different Site Types
The specifics depend on your setup, but the principle is consistent across all of them.
Static HTML or custom-built sites: Add <link rel="me" href="URL"> in your <head> for each external profile. For visible links, add rel="me" to the anchor tag alongside any other relationship attributes.
WordPress: Several plugins handle this, or you can add to your theme's header. The SEO plugins (Yoast, Rank Math) have social profile fields that may not add rel="me" automatically, so verify the output.
Eleventy (what this site is built on): Add to the head partial in your base layout. Keep a consistent list in a data file so it stays synchronized with your JSON-LD sameAs array.
The critical point about synchronization: Your rel="me" links and your JSON-LD sameAs array should be identical. They're two representations of the same fact: these external URLs all represent the same entity as this domain. Keeping them in sync means updating one when you update the other.
Which Platforms Support the Reciprocal Link
Not every platform allows you to add a custom URL that will be treated as a rel="me" confirmation. Some platforms add rel="nofollow" or rel="ugc" to user-provided links, which doesn't invalidate the link entirely but reduces its verification weight.
Platforms that handle this well:
Mastodon and ActivityPub platforms: These have native rel="me" support. If you add your website URL to your Mastodon profile and your site links to your Mastodon with rel="me", the green checkmark appears on your Mastodon profile. This is explicit bilateral verification.
GitHub: Profile links are followed. Adding your website to your GitHub profile and linking from your site with rel="me" creates a verifiable connection.
LinkedIn: The situation is more complex. LinkedIn often modifies outgoing links, but the URL field in your profile still provides enough of a signal when combined with other verification layers.
ORCID: ORCID's website link fields are specifically designed for this kind of verification and are treated with high trust by academic and research-oriented AI systems.
Google Business Profile: The website field creates a Google-verified link between your business profile and your domain. Not technically rel="me" in the HTML sense, but functionally equivalent in Google's ecosystem.
A Practical Identity Network Structure
For a professional like me, the structure looks something like this:
hibranwar.com serves as the hub. The <head> of every page includes <link rel="me"> pointing to LinkedIn, ORCID, GitHub, and Mastodon. The footer includes visible links to the same profiles, also with rel="me".
Each of those external profiles has hibranwar.com listed in the website or URL field.
The JSON-LD on hibranwar.com includes all the same URLs in the sameAs array.
The result is a web of confirmation that a machine can traverse. Start at hibranwar.com, follow the rel="me" link to ORCID, confirm that ORCID profile links back, check the JSON-LD, confirm consistency. Every check is a confirmation. Every confirmation adds to the entity's verifiability score.
Common Mistakes
Adding rel="me" to links that point to other people's profiles or company pages you're associated with but don't own. rel="me" is specifically about pages that are you or belong entirely to you. Your company's website is fine if you're the sole owner. A client's website is not.
Forgetting to update rel="me" links when you create new profiles. The value compounds with more nodes. When you create a new external presence, add it to the network immediately.
Neglecting the reciprocal side. The most common failure: adding rel="me" on your site but never adding your website URL to the external profile. Without the reciprocal link, the verification chain is broken.
Using rel="me" on links to profiles you can't control or update. If you link to a profile you might lose access to, that broken link in the chain can hurt rather than help.
The Compound Effect
Entity verification is not a one-time task. It's infrastructure that compounds. Every new node you add to your rel="me" network adds another verification path. Every external platform that supports the reciprocal link adds another independent source confirming your identity.
I'm building this network deliberately, adding new nodes as I establish presence on new platforms, always maintaining the consistency between rel="me" links, JSON-LD sameAs arrays, and the actual profiles I control.
The businesses and individuals that build this infrastructure now are creating something that gets stronger over time. Each verification layer makes the next one easier to establish. The network effect of identity verification is real.
Two characters. me. It's not the flashiest technical implementation. But in the context of building an entity identity that AI systems and search engines can trust, it might be the highest return-on-effort element in the entire stack.