Remove Blink Elements

What this check actually flags

This check fires when a page contains the <blink> element, or the CSS declaration text-decoration: blink, anywhere in its rendered HTML. Blink was a proprietary Netscape Navigator invention from the mid 1990s that made text flash on and off. It was never part of any official HTML specification, not HTML 3.2, not HTML 4.01, not HTML5. Internet Explorer never supported it, Chrome never supported it, and Firefox, the last holdout, removed the flashing behavior in Firefox 23 back in 2013.

So why does a check for it still exist in 2026? Because I still find it. Old WordPress themes, hand-coded brochure sites from 2004 that got migrated three CMS generations forward, legacy CMS WYSIWYG editors that let someone paste in markup twenty years ago, and template snippets copied from ancient forum posts. The tag itself no longer blinks anywhere, browsers now treat it as an unknown inline element and render the text statically, but its presence tells you something important about the health of the codebase you are standing on.

Why it matters for SEO, even though Google does not penalize it

Let me be straight with you: there is no "blink penalty." Google's rendering pipeline, which is based on an evergreen Chromium, simply ignores the tag and indexes the text inside it normally. Your rankings will not jump the day you delete a blink tag. Anyone telling you otherwise is selling something.

The real value of this check is diagnostic, and in my experience it is one of the more reliable canaries you can find in a crawl:

• It flags template rot. Where there is one deprecated element, there are usually friends: <marquee>, <font>, <center>, table-based layouts, inline event handlers. Pages built on that foundation tend to have real, measurable problems: bloated DOM, poor Core Web Vitals, broken mobile rendering.
• It creates invalid HTML. Unknown elements force the parser to guess. One stray unclosed legacy tag usually parses fine, but stacked parser guesswork across a messy template is exactly how content ends up in unexpected places in the DOM tree that Google renders.
• It is an accessibility violation waiting to happen. If any environment still honors the blink behavior (some email clients and embedded webviews have surprised me), flashing content violates WCAG 2.2.2 (Pause, Stop, Hide) and, at certain flash rates, WCAG 2.3.1 (Three Flashes or Below Threshold), which exists because flashing content can trigger photosensitive seizures. That is legal exposure in plenty of jurisdictions, not just bad UX.
• Accessibility and page experience feed the same quality picture. Google's quality systems reward pages that people can actually use. Anything that degrades usability for part of your audience is working against you, whether or not a named ranking factor covers it.

A short history, because it explains the fix

The tag reportedly started as a late-night joke inside Netscape, and the web spent two decades getting rid of it. The practical takeaway from that history: no user-facing behavior depends on blink anymore, so removal is a zero-risk edit. You are deleting markup that does literally nothing in any current browser.

How to detect it on your site

Do not trust a visual check. Since nothing blinks anymore, the tag is invisible to the eye. Go to the source:

1. Crawl with a custom search. In Screaming Frog, set up Custom Search (Configuration, then Custom, then Search) for <blink and text-decoration: blink or text-decoration:blink, then crawl the site. Sitebulb can do the same with its content search. This finds every affected URL in one pass.
2. Grep the codebase. If you have repo or server access, grep -ri "<blink" . across templates, theme files, and stored content is faster than any crawl and catches cases that only render under certain conditions.
3. Query the database. On WordPress, blink tags often live inside post_content, not the theme. A quick SELECT ID FROM wp_posts WHERE post_content LIKE '%<blink%' tells you exactly which posts to clean.
4. Validate a sample. The W3C validator (validator.w3.org) flags <blink> as an unknown element, useful for spot checks on individual templates.

How to fix it, step by step

1. Locate every instance using the detection methods above. Fix the template once instead of fixing fifty pages generated by it.
2. Unwrap, do not just delete. Remove the opening and closing tags but keep the text content inside them. Deleting the whole node can silently remove copy someone wrote for a reason.
3. Decide whether the emphasis still matters. If someone marked that text as blinking in 2003, they wanted attention on it. If the message still matters, restyle it with a highlight, a callout box, or <strong>. If it says "NEW for spring 2005!", kill it entirely.
4. Check for CSS and JS equivalents. Search stylesheets for text-decoration: blink and keyframe animations that toggle opacity or visibility in a loop. A CSS animation that flashes text more than three times per second recreates the exact accessibility problem with modern syntax. If a flashing effect must stay for some business reason, honor the prefers-reduced-motion media query and keep it under the WCAG flash thresholds.
5. Re-crawl to confirm zero instances, then run the affected templates through the W3C validator to catch any sibling legacy tags you exposed along the way.

Legacy elements reference

While you are in there, sweep for the whole family. Here is what I check in the same pass:

Do this, not that

What good looks like

A clean bill of health here means a full-site crawl with custom search returns zero matches for <blink and text-decoration: blink, your templates validate without obsolete-element warnings, and any attention-grabbing animation left on the site respects reduced-motion preferences and stays under three flashes per second. More broadly, treat a blink hit as an invitation to audit the whole template generation it came from. The blink tag was never your problem; the fifteen-year-old markup around it usually is.

FAQ