Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesTo remove the common ?ver= suffix from WordPress CSS and JavaScript URLs, either enqueue the asset with a null version or remove only the ver argument with the stylesheet and script loader filters. Do this only after choosing another cache-invalidation method, such as hashed filenames or a deployment purge. A query string is a cache-busting signal, not automatically a performance defect, and removing it does not guarantee a faster site.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What a query string on a WordPress asset does
A browser request such as /wp-content/themes/example/style.css?ver=6.6 contains a path and a query string. WordPress commonly appends ver when a stylesheet or script is registered or enqueued with a version. If the version argument is false, WordPress can use the installed WordPress version. The wp_enqueue_style() reference describes the version as a string added to the URL for cache busting; the script registration API follows the same model.
As an Amazon Associate I earn from qualifying purchases.
When the version changes, a browser, reverse proxy or CDN normally treats the URL as a new cache key and fetches the changed file. That lets a site keep long cache lifetimes without serving an old stylesheet after an update. Removing the parameter makes the URL look cleaner and may make cache keys more consistent on a particular stack, but it removes one signal that tells caches when an asset changed.
Should you remove ?ver=?
There is no universal speed or SEO gain. The practical result depends on your cache headers, CDN rules, browser cache, asset revisioning and the requests visible in your waterfall. Documentation for the Autoptimize project notes that the measured effect of removing ver can be little or none. A performance audit flag is therefore a reason to investigate, not proof that every query string should be stripped.
#1 Best Overall
Reasons to keep the parameter
- WordPress or your deployment process already changes the version whenever CSS or JavaScript changes.
- Your CDN and browser cache correctly use the complete URL as a cache key.
- Several plugins depend on their own query parameters or signed asset URLs.
- You cannot reliably purge every relevant cache after an asset deployment.
Reasons to remove only the version parameter
- Your cache layer handles static files more efficiently with stable, parameter-free keys.
- You use filename revisions, such as
app.8f31c.css, so a changed file receives a new URL. - You have a documented purge step for page, object, browser and CDN caches.
- Your audit shows a real cache-key problem rather than a theoretical warning.
Do not remove every query string from every URL. Tracking parameters, application filters, signed URLs and third-party API parameters can be functional. The safe target is local, static CSS and JavaScript, normally the ver parameter only.
Choose an implementation
| Approach | Scope | Cache-invalidation responsibility | Exclusions and rollback | Best fit |
|---|---|---|---|---|
Pass null when enqueueing |
One stylesheet or script that you control | You must provide filename revisioning or a purge process | Naturally limited; remove one argument to roll back | A theme or custom plugin with disciplined asset releases |
| Use loader filters | All matching frontend URLs generated through WordPress | You must verify every affected asset and preserve another revision method | Can be restricted to local .css/.js; remove the filters to roll back |
A site where many enqueue calls cannot be edited |
| Use a plugin | Usually frontend local CSS and JavaScript | Depends on the plugin and your cache stack | Review exclusions, updates and compatibility; deactivate to roll back | Owners who do not maintain PHP code |
| Change cache-layer handling | May affect cache variants rather than the rendered asset URL | Controlled by the cache or CDN configuration | Can also affect page-cache query strings; rollback requires restoring the setting | Sites with an administrator who understands the cache configuration |
Method 1: omit the version when you enqueue an asset
If you own the enqueue call, this is the narrowest solution. WordPress documents null as the version value that intentionally omits the version query parameter. The omission applies to that call only; it does not rewrite assets added by other plugins or by the parent theme.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →<?php
wp_enqueue_style(
'site-style',
get_stylesheet_uri(),
array(),
null
);
wp_enqueue_script(
'site-script',
get_template_directory_uri() . '/assets/site.js',
array(),
null,
true
);The last argument in the script example requests placement in the footer where the theme supports it; it is unrelated to query-string removal. Keep the dependency array accurate so that eliminating the version does not hide an ordering problem.
Use this with a replacement revision strategy
A stable URL such as site.js can remain cached after you deploy new code. Prefer one of these approaches:
- Generate a content hash in the filename, for example
site.4c92e1.js, and enqueue that filename. - Use a build system that writes a new revisioned filename for every production build.
- Run a documented purge of the relevant browser, reverse-proxy and CDN caches after changing the file.
- Keep a deliberate, short cache lifetime if neither filename revisioning nor reliable purging is available.
Do not change a version to false expecting it to disappear. In WordPress enqueue APIs, false can cause WordPress to use its installed version. Use null when omission is intentional.
Method 2: remove only ver with WordPress filters
When you cannot edit every enqueue call, WordPress provides URL filters. style_loader_src receives a fully qualified stylesheet URL, and script_loader_src is the analogous script hook. The following production pattern leaves the administration area alone, checks the file extension, skips a different host such as a third-party service or CDN, and removes only ver.
Free tools Windows power users keep installed
One-click scans. No signup required.
<?php
function freedom_remove_ver_query_arg( $src ) {
if ( is_admin() ) {
return $src;
}
$parts = wp_parse_url( $src );
if ( ! $parts || empty( $parts['path'] ) ) {
return $src;
}
$extension = strtolower( pathinfo( $parts['path'], PATHINFO_EXTENSION ) );
if ( ! in_array( $extension, array( 'css', 'js' ), true ) ) {
return $src;
}
$home_host = wp_parse_url( home_url( '/' ), PHP_URL_HOST );
$asset_host = isset( $parts['host'] ) ? $parts['host'] : '';
if ( $asset_host && $home_host && strtolower( $asset_host ) !== strtolower( $home_host ) ) {
return $src;
}
return remove_query_arg( 'ver', $src );
}
add_filter( 'style_loader_src', 'freedom_remove_ver_query_arg', 10, 1 );
add_filter( 'script_loader_src', 'freedom_remove_ver_query_arg', 10, 1 );Why this filter is deliberately limited
is_admin()prevents the frontend rule from changing the dashboard. If your project has a special frontend-like admin route, test that route separately.- The extension check avoids touching fonts, images, feeds, REST endpoints and dynamically generated URLs.
- A URL with no host is normally a relative, local URL. A URL with a host is compared with the site host; a different host is returned unchanged.
- Only
veris removed. Other parameters remain available to code that needs them.
If your static files are intentionally served from a separate CDN hostname, the host check will skip them. That is usually safer than altering a third-party URL. If you control that CDN and have a documented reason to modify its URLs, adapt the allow-list explicitly rather than deleting the host test for every external resource.
Do not use a no-op query-removal function
A common copy-and-paste error parses a URL and then calls remove_query_arg() without passing actual argument names. That function requires explicit keys. A function that supplies an empty list can silently return the original URL, while an overbroad function can remove parameters required by an integration. The example above targets the known ver key instead.
Escaping and output safety
The WordPress reference for remove_query_arg() warns that its return value is not escaped by default. In a filter used by WordPress’s normal style and script output, follow the surrounding API’s escaping conventions and test the rendered markup. If you use the helper in your own HTML, escape the final URL with the appropriate WordPress escaping function, normally esc_url() for an HTML attribute. Never concatenate an untrusted query value into markup.
Method 3: use a plugin or cache layer
Frontend asset-removal plugins
WordPress.org includes plugins titled “WP Remove Query Strings From Static Resources” that describe frontend-only removal, targeting local CSS and JavaScript while ignoring external resources. A similar plugin from InfoBilisim offers an exclusion hook. These tools can be useful when you do not maintain a child theme or custom plugin, but they are still code running on production pages.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Before activating one, check its current update activity, supported WordPress and PHP versions, exclusion controls, interaction with minification or concatenation, and whether it has a simple deactivation path. Take a backup or stage the change first. A plugin that removes parameters globally without distinguishing local assets can break a signed URL or a vendor script.
Cache-plugin and CDN settings
Some cache layers expose a setting that drops query strings when deciding how to cache CSS and JavaScript enqueued by WordPress. LiteSpeed Cache documentation, for example, describes behavior that skips external URLs and selected exclusions while changing how cache variants are handled. That setting is not identical to rewriting the URL in the HTML:
- An asset-URL filter changes what the browser requests.
- A cache-key setting can leave the browser-visible URL unchanged while making the server treat several variants as one cached object.
- A page-cache query-string setting can affect URLs for whole pages, including tracking or filter parameters.
Keep page-cache controls separate from static-asset controls. Dropping a parameter from a product filter, login flow, signed download or analytics URL can change application behavior. Read the cache layer’s exclusion documentation and test both cache hits and misses before enabling a broad rule.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Build a reliable cache-invalidation plan
Removing ?ver= is safe only when a changed file cannot be mistaken for the old file indefinitely. Choose one primary mechanism and document it for anyone who deploys the site.
Filename revisioning
Content-hashed filenames are the most self-contained option. A build produces a new name when bytes change, and the old name can remain cached without affecting visitors who receive the new HTML. The enqueue call must reference the generated manifest or revisioned filename; merely renaming a file manually without updating the enqueue code creates a 404.
Deployment purges
If filenames stay constant, purge every layer that can hold the asset: the page cache that emits the HTML, any object or reverse-proxy cache, the CDN, and, where relevant, a browser cache. A purge that reaches only the CDN can still leave old HTML in a page cache, while a new HTML document can point to a file retained in an intermediate cache.
Cache headers
Long-lived Cache-Control headers make invalidation more important, not less. Review the actual response headers and cache status for a CSS and a JavaScript file. Do not infer behavior from the presence or absence of a query string alone.
Verification checklist after deployment
- Inspect the rendered page. View source or use browser developer tools and list the stylesheet and script URLs. Confirm that only intended local
.cssand.jsURLs changed, and that required non-version parameters remain. - Check both authentication states. Test a logged-out page and a logged-in page. The administration area should retain its normal asset behavior unless you intentionally changed it.
- Test responsive templates. Check desktop and mobile layouts, pages using a different template, and any route that conditionally enqueues an asset.
- Exercise third-party integrations. Test consent tools, payment widgets, embeds, analytics and any vendor script. External resources should remain untouched by a local-only rule.
- Purge the planned caches. Clear page, object, browser and CDN caches according to your deployment procedure.
- Change a real asset. Modify a harmless CSS rule or JavaScript comment, deploy it, and confirm that a fresh request delivers the changed file. If it does not, restore versioning or implement filename revisioning before continuing.
- Re-run the audit. Compare the request waterfall and measured cache headers on your site. Report the observed result rather than promising a universal percentage improvement.
Troubleshooting common failures
The query string is still present
Another plugin, the parent theme or an inline-generated tag may be adding the URL after your code runs. Search the rendered HTML and identify the handle or component that owns it. If the asset is external, the local-only function intentionally leaves it unchanged. If you used the enqueue method, remember that it changes one call only.
Styles or scripts appear stale
This indicates missing invalidation, not a reason to remove more parameters. Purge all cache layers, verify the response body and headers, then adopt filename revisioning or restore a version argument. Do not ask visitors to perform a hard refresh as the permanent deployment strategy.
A plugin or integration breaks
Disable the filter or plugin and retest to isolate the cause. Inspect whether the affected URL had a parameter other than ver, a signature, a nonce or a vendor-specific value. Add an explicit exclusion for that handle or host rather than broadening the removal rule.
The site receives a PHP warning
Check that the code is in a loaded custom plugin or child theme, that the function name is unique, and that it is not declared twice. Confirm the site’s PHP version and test the code on staging. A syntax error in a theme file can take down the frontend, so keep a recovery path through file access or a deployment rollback.
The audit score did not change
That result is plausible. Removing a short query string does not reduce the file’s bytes, the number of requests, render-blocking work or server latency. Address the largest measured bottleneck in the waterfall instead of retaining a risky change for a cosmetic score.
Recommended decision
For a custom theme or plugin, start with null on the specific enqueue call and pair it with hashed filenames or a tested purge. For a site with many independently managed assets, use the local-only loader filters and remove only ver. Choose a plugin when code ownership is the constraint, but review its exclusions and rollback path. Treat cache-layer settings as a separate optimization and never apply a blanket rule to every URL parameter.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
