How a Dead Polyfill.io Link Got My Entire GitHub Pages Domain Flagged as Dangerous

Question

I recently published a digital anthology project at nevmenandr.github.io/WLA.
The setup was smooth – I used Obsidian with the excellent
obsidian-publish-mkdocs plugin to generate a clean, documentation‑style site.

Everything worked beautifully… until Google Chrome started showing a bright red warning:
"Deceptive site ahead" – not just for my new project, but for every site hosted under my nevmenandr.github.io domain.

---

The Culprit: A Single, Innocent‑Looking Script Tag

While inspecting the generated HTML, I noticed lines where the polyfill.io link caught my eye. I tried visiting it directly (the full URL with /v3/polyfill.min.js?features=es6 on the polyfill.io domain).
Result: 401 Authorization Required – a dead service.

---

A Critical Red Flag: The Repository Is Stale

Digging deeper, I realised that the obsidian-publish-mkdocs repository on GitHub has not been updated for over two years.

This is a classic warning sign:

• The plugin still bundles legacy dependencies that were once free but have since changed hands.
• The maintainer hasn't patched or removed deprecated resources.
• No security audits or dependency refreshes have occurred in that time.

While the tool works brilliantly out‑of‑the‑box, it's effectively unmaintained – and that's a risk you inherit as a user.

---

Why This Triggered Google's Safe Browsing

polyfill.io used to be a free, trusted CDN. But the domain was sold to a new owner who now requires payment and returns 401 (or even malicious redirects) for unauthenticated requests.

Google's crawler saw that my site included a script from a domain that now behaves suspiciously – and flagged the entire nevmenandr.github.io origin as a potential threat. This is a domain‑level penalty, meaning all my other GitHub Pages projects were blocked too.

---

The Fix: Step‑by‑Step Recovery Guide

If you ever face this, here's the exact process that got my site back online within ~24 hours.

1. Remove the Offending Resource

• Locate and delete the problematic script tag from your HTML template.
  In my case, I disabled the polyfill inclusion in the MkDocs theme config (or simply removed the line from the generated index.html).
• Rebuild and redeploy your site to GitHub Pages.

2. Verify the Site is Clean

• Visit your URL in a private/incognito window to confirm the red warning still appears (it will, until Google re‑crawls).
• Use the Google Transparency Report tool (search for "Google Transparency Report" and then enter your domain in the Safe Browsing section) to check your domain's current status.

3. Claim Ownership in Google Search Console

• Go to Google Search Console (search for it – it's Google's official tool for webmasters).
• Add your site as a property (use the URL‑prefix type, e.g., https://nevmenandr.github.io/WLA/).
• Verify ownership using the recommended method – for GitHub Pages, the easiest is:
  1. Download the HTML verification file from Search Console.
  2. Add it to the root of your repository (/path/to/your/repo/).
  3. Commit and push – GitHub Pages will serve it automatically.

4. Request a Review

• In Search Console, navigate to Security & Manual Actions → Security Issues.
• If the warning is still active, you'll see a "Request Review" button.
• In the review form:
  • Explain clearly that you've removed the external resource that caused the issue.
  • Mention that you've scanned your site for any other suspicious content.
  • If you use any other external scripts, list them and confirm they are safe.

5. Wait (Usually 24‑48 Hours)

• Google's team will review your request. In my case, the domain was cleared in about 24 hours.
• You can monitor the status in Search Console – it will change from "Pending" to "Approved" or "Rejected".

---

Key Lessons for Developers

• Third‑party scripts are liabilities. Always audit CDN links – especially free ones that can change ownership or monetisation models overnight.
  Consider self‑hosting critical libraries or using well‑established CDNs with clear SLAs (e.g., cdnjs, jsdelivr).

• Check the maintenance status of your tools.
  A plugin that hasn't seen a commit in two years is a ticking time bomb. Always review the last update date before relying on any open‑source dependency in production. If it's stale, fork it, update the dependencies yourself, or look for an actively maintained alternative.

• Google Safe Browsing penalises at the domain level.
  A single compromised resource can take down all your sub‑projects, including unrelated ones. This is particularly painful on GitHub Pages where you share the *.github.io namespace.

• Automate dependency checks.
  Add a step in your CI/CD pipeline to test external URLs for HTTP 2xx responses. For example, with a simple curl check:

  if ! curl -s -o /dev/null -w "%{http_code}" https://polyfill.io/v3/polyfill.min.js | grep -q "200"; then
    echo "⚠️  Polyfill.io is unreachable – aborting build"
    exit 1
  fi
  

• Know the recovery path.
  Having a verified Google Search Console property is not optional if you publish public sites. It's your only channel to communicate with Google's security team when false positives occur.

• Don't panic – the process works.
  The warning looked scary, but the fix was straightforward. The key is to act quickly, be transparent in your review request, and double‑check that no other deprecated services remain.

---

Final Thought

Open‑source tools like obsidian-publish-mkdocs are brilliant for productivity – but they often bundle legacy dependencies for maximum compatibility, and when a repository stagnates for years, those dependencies can rot. As developers, it's our responsibility to review every external asset and check the pulse of our toolchain before going live.

One dead polyfill link and an unmaintained plugin cost me a day of heartache. Don't let it happen to you. 🚀