How to Fix Protocol-Relative URLs
A protocol-relative URL is written as `//example.com/page` instead of `https://example.com/page`, letting the browser fill in whichever protocol served the current page. It was a genuinely useful trick during the years when sites ran on both http and https, but the web is https-by-default now, and the pattern has quietly become an anti-pattern with no upside left. It's a low-severity notice: find these URLs and rewrite them to explicit `https://`, or a root-relative `/path` for links on your own domain.
What this means
A protocol-relative (or scheme-relative) URL omits http: or https: and starts directly with //, for example //cdn.example.com/style.css or <a href="//example.com/page">. A browser resolves this by reusing whatever protocol loaded the current page: on an https:// page it fetches the https:// version of that resource; on an http:// page, the http:// version.
The pattern was popularized around 2010 to solve one specific problem: a resource, often a shared CDN asset, that legitimately needed to work whether the page embedding it was served over http or https. Writing the URL once without a scheme meant it "just worked" either way and avoided triggering a mixed-content warning on the secure pages that used it. For that narrow era, it was a sensible piece of engineering.
That era is over. Browsers flag or actively block plain HTTP pages, free certificates and one-click TLS are standard on every host, and HSTS keeps entire domains on https permanently. The scenario protocol-relative URLs were designed for, a resource genuinely served both ways, is now rare to nonexistent for most sites. What's left is a URL format that depends on context to resolve correctly instead of just saying what it means.
This is flagged as a notice, the lowest severity tier the audit uses. On an all-https site these links resolve correctly in every modern browser almost all the time. The concern isn't that something is currently broken; it's that the pattern is unnecessary today and carries a real, if narrow, edge case.
Why it matters
The practical risk shows up outside the browser. Copy a protocol-relative URL into a place with no "current page" to inherit a protocol from, a markdown file, a PDF, a plain-text email, an RSS reader, or a non-browser HTTP client, and there's nothing to resolve it against. Some tools default to http://, quietly downgrading a link you intended to be secure; others reject it outright as an incomplete URL. A link that always works in a browser doesn't necessarily work in every tool that has to parse it standalone.
It can also reintroduce mixed content by accident. If any page on your site is ever reachable over plain http, a legacy redirect gap, a staging mirror, an internal preview link, every protocol-relative resource on that page silently loads over http too, quietly recreating the exact insecure-resource problem your HTTPS migration was meant to close. An explicit https:// can't make that mistake.
There's a smaller but real tooling angle: some link parsers, validators, and simpler crawlers, including a few AI browsing and fetch tools with naive base-URL handling, don't resolve scheme-relative URLs the way a browser does, and can misread //example.com/page as a same-origin relative path rather than a link to an external site. Writing the full https:// removes that ambiguity for anything that isn't a browser.
Honestly, none of this is an SEO ranking factor, and Google does not treat protocol-relative URLs as a search-visibility issue. The reason to fix it is robustness and clarity: removing a legacy pattern that no longer serves the purpose it was built for, not chasing a ranking or speed gain that isn't there.
How to fix it
- 1
Find every protocol-relative reference
Search your templates, stylesheets, and stored content for
href="//,src="//, andurl(//. Browser DevTools won't flag these on their own, since they resolve fine on a modern https page, so a source-level search across templates, theme options, and page content is the reliable way to find them, not a live network check. - 2
Rewrite external references to explicit https://
For third-party resources, CDNs, web fonts, embeds, and widgets, change
//fonts.googleapis.com/...tohttps://fonts.googleapis.com/.... Virtually every external host worth linking to today serves https, so this is typically a safe, mechanical find-and-replace rather than something that needs case-by-case judgment. - 3
Use root-relative paths for your own domain
For links and assets on your own site, prefer a root-relative path like
/assets/logo.pngor/aboutover either the protocol-relative or fully-qualified form. It inherits both the host and the protocol automatically, stays correct if you move between staging and production, and is shorter to write and maintain than repeating your own domain everywhere. - 4
Check stored content, not just template code
Protocol-relative URLs often hide in database content (old posts, page-builder fields), theme or customizer settings (a logo or background image field), and CSS @import or url() declarations, not just your template files. A template-level fix alone will miss anything pasted directly into content, so search content storage too.
- 5
Re-crawl and confirm
Re-run the audit and spot-check with view-source that
//-prefixed URLs are gone or down to zero. Because this is a low-severity notice rather than a broken-link error, it's reasonable to batch the fix in with other routine cleanup instead of treating it as urgent.
Example
<!-- BEFORE: protocol-relative, depends on the current page's scheme -->
<script src="//cdn.example.com/lib.js"></script>
<link rel="stylesheet" href="//fonts.googleapis.com/css?family=Roboto">
<a href="//example.com/about">About us</a>
<!-- AFTER: explicit for third-party, root-relative for your own domain -->
<script src="https://cdn.example.com/lib.js"></script>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto">
<a href="/about">About us</a>Protocol-relative URLs rewritten to explicit https:// for third-party resources and a root-relative path for an internal link.
Platform-specific steps
Shopify's built-in asset_url Liquid filter has historically output protocol-relative URLs (//cdn.shopify.com/...) for theme assets; this is a platform default, not a mistake in your theme, and generally resolves fine since Shopify storefronts are https-only today. Focus your cleanup on custom code you've added (embeds, third-party script tags, hardcoded CSS) rather than the platform's own asset filter.
Check theme Customizer fields (logo, background image) and any plugin settings that store a CDN or asset URL; these sometimes save the protocol-relative form. A database search-and-replace, via WP-CLI's wp search-replace or the Better Search Replace plugin, for //yourdomain.com to https://yourdomain.com catches instances pasted into post content.
Grep the codebase specifically for "//" and (// patterns across HTML, CSS, and any templating layer. Fix @import url(//fonts.googleapis.com/...) and similar CSS references alongside HTML attributes; both are equally easy to miss if you only check markup.
Frequently asked
No, not on a modern all-https site; they resolve correctly in every current browser. This is a low-severity notice about a legacy pattern and a narrow edge case outside the browser, not a functional bug affecting your site today.
It solved a real problem during the mixed http/https era: a shared resource, often a CDN asset, that needed to work correctly whether the embedding page was secure or not. Writing the URL without a scheme let it inherit whichever protocol the page used. Since almost the entire web is https-only now, that original problem rarely applies anymore.
Use explicit https:// for third-party or cross-origin resources like a CDN or font provider. Use a root-relative path like /about for links and assets on your own domain; it inherits your site's protocol and host automatically and needs no updating if your domain setup changes.
Not meaningfully. It isn't a documented Google ranking factor and won't move a PageSpeed score on its own. The benefit is robustness and clarity, removing a legacy pattern that depends on context to resolve correctly, not a search-visibility or performance gain.
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.