Fix Unsafe target="_blank" Links (rel="noopener")
Your audit flagged links that open in a new tab (target="_blank") without rel="noopener". That reference lets the destination page reach back into your original tab through window.opener, which enables a phishing trick called reverse tabnabbing. The fix is adding one attribute to the affected anchor tags.
What this means
This warning means one or more links on the page use target="_blank" (open in a new tab or window) without also carrying rel="noopener" or the broader rel="noopener noreferrer".
When a link opens with target="_blank", the newly opened page historically gets a JavaScript reference back to your page through window.opener. That reference lets the destination page run window.opener.location = "https://phishing-site.example" and silently redirect your original tab to a lookalike login page while the user is focused on the new tab. This attack is called reverse tabnabbing.
Adding rel="noopener" severs the link: the new page opens with window.opener set to null, so it can no longer touch your tab. rel="noreferrer" does the same thing and additionally strips the Referer header, so the destination doesn't learn which page the click came from.
Current versions of Chrome, Firefox, and Safari now apply noopener behavior automatically to target="_blank" links, so the practical risk on up-to-date browsers is low. The explicit attribute is still the correct, portable fix. Audit tools flag it because you can't assume every visitor is on a current browser, in-app webviews and older embedded browsers still expose window.opener, and the explicit attribute is what security scanners and code reviewers check for.
Why it matters
This is a Security & HTTPS warning, not a critical outage, so it won't sink your rankings on its own. It still matters for a few concrete reasons.
Security and trust: Reverse tabnabbing is a real phishing vector. If an attacker controls or later compromises any page you link to with an unprotected target="_blank" (user-generated content, comment links, forum posts, affiliate URLs, or a partner site that gets hacked), they can hijack your tab. For sites that handle logins or payments, that's a direct trust and liability problem.
Privacy and referrer leakage: Without noreferrer, a new-tab click sends your page URL in the Referer header to the destination. On URLs with query strings (session tokens, tracking IDs, internal paths) that can leak more than you intend.
SEO and quality signals: Google's Safe Browsing and quality systems care about whether a site exposes users to phishing and malicious redirects. Clean security hygiene supports how trustworthy your site looks. It's also a routine line item in security-header and Lighthouse-style audits, so leaving it unfixed drags down the score that reviewers and AdSense policy checks see.
AI answer engines: Crawlers behind ChatGPT, Perplexity, and Google AI Overviews favor sources they can classify as safe and well-maintained. Clean security hygiene won't directly win citations, but a site that trips malware or phishing flags can get demoted or excluded from the pools these systems draw from. Fixing this is part of presenting as a maintained, trustworthy source.
How to fix it
- 1
Add rel="noopener" to every target="_blank" link
The core fix in raw HTML is one attribute. Any anchor that opens a new tab should carry
noopenerat minimum, plusnoreferrerif you also want to hide the referrer. Change<a href="https://example.com" target="_blank">to<a href="https://example.com" target="_blank" rel="noopener noreferrer">. If the link already has arelvalue likenofolloworsponsored, append to it space-separated:rel="nofollow noopener". - 2
Find every affected link instead of guessing
Search your templates and content for
target="_blank"and check which hits lackrel="noopener". In a codebase, grep fortarget="_blank"and inspect therelon each match. For a live page, re-run the audit or paste this into the browser console:Array.from(document.querySelectorAll('a[target="_blank"]:not([rel*="noopener"])')).map(a => a.href). That surfaces links buried in third-party embeds, ad snippets, and old posts you'd otherwise miss. - 3
Fix it at the template or component level
Hardcoding the attribute on every link doesn't scale. In React or Next.js, put
rel="noopener noreferrer"in your reusable Link or ExternalLink component so every new-tab link inherits it. In server-rendered templates (PHP, Liquid, Django, and similar), do the same in the partial that renders links. This is the durable fix: new content stays safe automatically instead of relying on authors to remember. - 4
Auto-patch links you can't edit by hand
For large sites or user-generated content, add the attribute programmatically at render time. Sanitizing on the server when content is saved is best, because the stored HTML is already safe and crawlers see the correct markup. If you use a rich-text editor, configure its link plugin to inject
relon insert. A client-side script works as a last-resort safety net:document.querySelectorAll('a[target="_blank"]:not([rel*="noopener"])').forEach(a => a.rel = (a.rel + ' noopener noreferrer').trim());. - 5
Re-run the audit to confirm the fix
After deploying, purge any CDN or page cache and re-crawl the page to confirm the warning clears. If it persists, the crawler is likely still seeing a cached copy, or the attribute is on some links but not all. The console query from step two shows exactly which anchors still need it.
Example
<!-- Flagged: opens a new tab with no protection -->
<a href="https://external-site.com" target="_blank">Visit site</a>
<!-- Fixed: nulls window.opener and strips the referrer -->
<a href="https://external-site.com" target="_blank" rel="noopener noreferrer">Visit site</a>
<!-- Combining with an SEO rel value (space-separated, all valid together) -->
<a href="https://affiliate.com/deal" target="_blank" rel="sponsored noopener noreferrer">Sponsored deal</a>
<!-- Safety-net script: patch every unprotected new-tab link at runtime -->
<script>
document.querySelectorAll('a[target="_blank"]:not([rel*="noopener"])')
.forEach(function (a) {
a.rel = (a.rel + ' noopener noreferrer').trim();
});
</script>Before and after: making a new-tab link safe
Platform-specific steps
WordPress core adds rel="noopener" automatically to new-tab links created in the block and classic editors (this has shipped since version 4.7.4), so editor links are already safe. The warning usually comes from custom HTML blocks, theme or template files, or page-builder widgets that bypass the editor. Fix those in the raw HTML. If a theme or plugin strips the attribute, add it back in the template or with a small output filter.
These SEO plugins don't manage rel="noopener" themselves; WordPress core handles it on editor links. What they control is nofollow and sponsored on external links. If you use their link settings, make sure the resulting rel still includes noopener (combine them, e.g. nofollow noopener). Neither plugin removes noopener, so the fix stays with core or your theme templates.
Edit the theme where new-tab links are generated. In your .liquid templates and sections, find anchors with target="_blank" and add rel="noopener noreferrer". For links inside product descriptions or rich-text metafields entered by staff, add the attribute when pasting HTML or run a one-time find-and-replace across content, since Shopify's rich text editor doesn't always inject it.
These hosted builders render most external links through their own UI, and current versions apply new-tab safety automatically. The gap is custom-code blocks and injected HTML: anywhere you paste your own <a target="_blank">. Add rel="noopener noreferrer" inside those blocks manually. You generally can't edit the platform's own link markup, so focus on your custom embeds.
Fix it at the component level, not per link. Create or update a shared external-link component that always renders target="_blank" rel="noopener noreferrer", and route all new-tab links through it. For Next.js <Link> used with target="_blank", pass the rel prop explicitly. The react/jsx-no-target-blank rule in eslint-plugin-react flags missing rel at build time, so keep it enabled to fail CI on regressions.
Grep your source for target="_blank" and add rel="noopener noreferrer" to each anchor that lacks it. If you build pages with a static-site generator (Hugo, Eleventy, Jekyll), fix it in the layout or partial, or in a Markdown link render hook, so all output is consistent. Many Markdown processors have a plugin or config option that auto-adds noopener to external links; enable it to keep new content safe.
Frequently asked
noopener sets window.opener to null in the new tab, blocking reverse tabnabbing but still sending the referrer. noreferrer does both: it nulls window.opener and strips the Referer header so the destination can't see which page linked to it. Use rel="noopener noreferrer" when you want both protections. Use noopener alone if you still need to pass referrer data, for example so a partner's analytics can attribute your traffic.
Not entirely. Chrome and Edge (since version 88), Firefox (since 79), and Safari (since 12.2) apply noopener behavior automatically to target="_blank" links, so most current-browser users are already protected. But older browsers and in-app webviews (links opened inside mobile apps) can still expose window.opener. The explicit attribute is also what security scanners, code reviewers, and audit tools look for, so adding it remains best practice.
No. noopener and noreferrer are security and privacy attributes that control browser behavior and the referrer header. They do not tell Google to ignore the link or withhold PageRank. That's the job of nofollow, sponsored, and ugc. You can safely combine them, for example rel="nofollow noopener", with no conflict.
For same-origin links the tabnabbing risk is essentially zero, since your own pages won't hijack your tab. Adding rel="noopener" anyway is harmless and keeps markup consistent, so audits pass cleanly. Many teams apply it to every target="_blank" link regardless of destination to avoid reasoning about origin on each link.
Usually one of three things: a cached copy is being crawled (purge your CDN or page cache and re-audit), the attribute is on some links but not all (check third-party embeds, ad code, and social-share widgets that inject their own anchors), or a typo like rel="noopenner" or rel="no-opener". Run document.querySelectorAll('a[target="_blank"]:not([rel*="noopener"])') in the console to see exactly which links still need it.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.