The Update URI plugin header tells WordPress where a plugin gets its updates. If it points anywhere other than the WordPress.org directory, WordPress will not offer a WordPress.org update for it. Agencies should set it on every custom or private plugin so a same-named public plugin cannot replace it.
The problem it solves
Before WordPress 5.8, a custom plugin that used the same slug as a plugin hosted on WordPress.org took a real risk, according to the core dev note: an update to the public plugin could overwrite it. Agencies name internal plugins things like client-forms or custom-checkout, and short generic names are likely to collide.
How it works
From WordPress 5.8, if the header value matches any URI other than the plugin's own WordPress.org page, WordPress will not try to update the plugin from the directory. The note gives examples: a URL on your own domain, a unique string, or the word false, which prevents updates unless code handles it. The header should be a valid URI with a unique hostname. Plugins hosted on WordPress.org do not need it.
There is also a filter, update_plugins_ followed by the hostname, which lets a third party supply updates for that hostname.
/*
* Plugin Name: Client Checkout Extras
* Update URI: https://updates.youragency.example/client-checkout-extras/
*/
Steps for an agency
- List your custom plugins from the inventory export.
- Open the main file of each and look for the header.
- Add one with a hostname you control, or false if updates are managed some other way.
- Test on staging that the Plugins screen no longer shows a directory update for it.
- Write down how updates for it will actually arrive, since the header only stops the wrong source.
What it does not protect
| Risk | Covered? |
|---|---|
| Directory plugin overwriting yours | Yes |
| Your own update server being compromised | No, secure that separately |
| Someone installing a lookalike by hand | No |
| A tampered package from your server | No, sign or verify it yourself |
If you run an update server, it becomes part of your supply chain. Protect the account and host as you would a package registry, and see our related post on why plugins must not update from elsewhere.
Choosing a value
A URL on a domain you control is the clearest option, because it documents where updates should come from. The word false is a good choice for a plugin that you update only through deployment. Keep a short note in your own repository saying which choice you made and why. If you hand the site to another team later, that note saves them from guessing why the plugin never shows an update in the dashboard.
Testing the result
After you add the header, open the Plugins screen on staging and check for update notices. Then rename nothing and change nothing else: the point is to confirm that the directory no longer offers an update for the plugin. If you maintain several custom plugins, add a short check to your release routine so a new plugin never ships without the header. A reviewer can catch a missing header in seconds when it is on the checklist.
Quick check
Do plugins on WordPress.org need this header?
No. The dev note says authors of directory plugins do not need it.
Is Update URI false a safe default?
It stops directory updates, but then nothing updates the plugin unless you handle it yourself.
Sources
Last reviewed: 19 October 2026.
