noopener, noreferrer, nofollow, sponsored, ugc: 6 myths about the rel attribute on your links

Look at the external links in most codebases and you'll find something like this:

<a href="https://example.org" target="_blank" rel="noopener noreferrer nofollow">

Ask why each value is there and the answers get vague. "Security." "SEO." "The linter told me to." The rel attribute has become a junk drawer where security, privacy, analytics and search hints all live together, and plenty of myths have grown around it.

Here are six of them.

Myth 1: "Every target="_blank" link needs rel="noopener" or it's a security hole"

This used to be true. A page opened with target="_blank" could access window.opener and redirect the original tab to a phishing page, a trick known as "tabnabbing".

Modern browsers changed the default: target="_blank" now implies noopener behaviour in current versions of the major browsers. So the vulnerability is largely closed for up-to-date users.

Reality: Adding rel="noopener" is still harmless and protects anyone on older browsers, so many teams keep it. But it's no longer the urgent fix it once was, and it isn't a reason to panic about old links.

Myth 2: "noopener and noreferrer are the same thing"

They overlap, but they're different:

• noopener prevents the new page from getting a reference to your window.
• noreferrer does that and stops the browser sending the Referer header, so the destination doesn't see which page the visitor came from.

Reality: noreferrer has a cost people forget: the site you link to can't see your traffic in their analytics. If you're linking to partners, sources or anyone you'd like to notice you, noreferrer hides you from them. Use it when you genuinely want privacy for the visitor, not by default.

Note too that the referrer is already trimmed by default in modern browsers, through the referrer policy, usually to just your domain for cross-site links. You can control this site-wide with a Referrer-Policy header rather than per link.

Myth 3: "nofollow stops search engines from following the link"

The name suggests it, but it's not a reliable way to keep a page out of search. Google, for example, has described nofollow (along with sponsored and ugc) as a hint rather than a strict directive. Search engines may still discover and crawl the destination through other routes.

Reality: nofollow signals "I don't vouch for this link". If you need a page kept out of search results, that's the job of noindex on the page itself, not an attribute on links pointing to it.

Myth 4: "Add nofollow to every external link to protect your SEO"

This one does real damage, mostly to the web. Blanket nofollow on every outbound link treats every source, reference and recommendation as untrustworthy. There's no well-established evidence that linking to good, relevant pages harms your own site.

Reality: Link normally to things you'd recommend. Use the specific values where they apply:

• sponsored for paid links, affiliate links and anything you were compensated for.
• ugc for links in user-generated content: comments, forum posts, profiles.
• nofollow for links you don't want to endorse that don't fit either category.

You can combine them, for example rel="ugc nofollow".

Myth 5: "rel values on links affect whether the link works"

They don't. Visitors clicking a nofollow, sponsored or noreferrer link reach the same page as with any other link. Which means the rel attribute has nothing to do with whether a link is broken.

Reality: A nofollow link to a dead page is still a dead link for your readers. Link checkers should check every link regardless of its rel values, and the ones in user-generated content, often marked ugc, are among the most likely to rot.

Myth 6: "Set it once in a component and forget it"

Centralising link rendering in a component is smart:

function ExternalLink({ href, sponsored = false, children }) {
  const rel = ["noopener", sponsored && "sponsored"].filter(Boolean).join(" ");
  return <a href={href} target="_blank" rel={rel}>{children}</a>;
}

But components get copied, wrapped and overridden. Markdown content, CMS fields and third-party widgets often bypass them entirely.

Reality: Check the rendered HTML now and then. A quick audit of a built page:

curl -s https://example.com/post | grep -o '<a [^>]*>' | grep -o 'rel="[^"]*"' | sort | uniq -c

If you see combinations nobody chose on purpose, a blanket nofollow on internal links for example, something in the pipeline is adding them.

A bonus: rel values on other elements

rel doesn't only appear on <a>. In the <head>, <link rel="canonical">, rel="alternate" and rel="preload" do entirely different jobs, and rel="me" is used to verify profile links between sites. They share an attribute name, not a purpose. When someone says "we need to fix our rel tags", it's worth asking which ones, because a change meant for outbound links in article content shouldn't touch the <head> at all.

The same applies to forms and areas: <form rel> and <area rel> accept some of the same values. Most audits only look at anchors, which is usually fine, but worth knowing if a tool reports something odd.

A sensible default

For most sites, this is enough:

• Internal links: no rel, no target="_blank".
• External editorial links: a plain link. Add noopener if you open them in a new tab and want belt-and-braces.
• Paid or affiliate links: sponsored.
• Links in comments and user profiles: ugc, possibly with nofollow.
• Privacy-sensitive outbound links: noreferrer, deliberately.

And whatever rel values a link carries, it still needs to lead somewhere. Checking that, across every page and every link, is what we do at linkbruno.com.

Related reading

• Should a broken external link fail your build? Comparing four CI policies, and the one I'd pick
• How to find mixed content (http:// links) on an HTTPS site
• How to find broken outbound links and replace them (using the Wayback Machine)
• The anatomy of a URL, and which part of it broke your link

What's in the rel attribute on your site's external links today, and does anyone on your team know why?