Hiding vs. restricting the WordPress REST API

Hiding the WordPress REST API and restricting the WordPress REST API are not the same thing.

Hiding usually means removing the metadata that advertises where the REST API is located.

Restricting means changing who is actually allowed to access REST API endpoints.

The difference is architectural:

Hide REST API discovery
→ clients are no longer told where the API is

Restrict REST API access
→ requests to the API are actually denied unless they meet your rules

A WordPress site can therefore stop advertising:

https://example.com/wp-json/

while the endpoint remains completely accessible to anyone who already knows or guesses the URL.

Conversely, a site can continue advertising the REST API while requiring authentication for protected requests.

This distinction matters because the REST API is a major part of modern WordPress. It is used by the Block Editor, plugins, custom applications, administrative interfaces and external integrations.

The official WordPress REST API Handbook describes the REST API as an interface for applications to interact with WordPress using JSON and notes that it forms the foundation of the WordPress Block Editor.

Blanket restrictions can therefore have much broader consequences than simply removing one line from the document <head>.

This guide explains how WordPress advertises the REST API, what hiding actually changes, how real REST API restrictions work, how authentication and permissions protect endpoints, and how to choose the narrowest policy that meets your security and privacy requirements without unnecessarily breaking WordPress.

What is the WordPress REST API?

The WordPress REST API allows software to interact with WordPress through HTTP requests.

Instead of rendering a normal HTML page, REST endpoints generally return structured JSON data.

A typical REST API root is:

https://example.com/wp-json/

Core WordPress routes commonly live under namespaces such as:

/wp-json/wp/v2/

For example:

/wp-json/wp/v2/posts
/wp-json/wp/v2/pages
/wp-json/wp/v2/categories
/wp-json/wp/v2/tags
/wp-json/wp/v2/users

Plugins can register their own namespaces and routes as well.

For a broader introduction to REST security, see WordPress REST API Security Basics.

Public REST data is not automatically a data leak

The WordPress REST API follows the site’s content visibility and permission model.

The official WordPress REST API handbook explains that content already public on the website is generally also publicly accessible through the API, while private, password-protected and otherwise restricted information requires appropriate authentication or permissions.

For example, if this post is publicly visible:

https://example.com/example-post/

its public representation may also be available through something like:

https://example.com/wp-json/wp/v2/posts/123

That is not inherently equivalent to exposing private information.

It is another representation of content that is already public.

How WordPress advertises the REST API

WordPress provides several REST API discovery mechanisms.

The official REST API Discovery documentation describes three important mechanisms:

• HTTP Link headers;
• HTML <link> elements;
• RSD discovery.

These mechanisms allow compatible software to discover the API without hard-coding:

/wp-json/

REST API discovery through the document head

WordPress can output a link such as:

<link
    rel="https://api.w.org/"
    href="https://example.com/wp-json/"
/>

This is generated through:

rest_output_link_wp_head()

The official rest_output_link_wp_head() documentation confirms that the function outputs the REST API link tag into the page header.

On some resources, WordPress can also output an alternate JSON representation for the current object.

REST API discovery through HTTP headers

WordPress can also advertise the API through an HTTP header such as:

Link: <https://example.com/wp-json/>; rel="https://api.w.org/"

The REST API discovery handbook describes the HTTP Link header as the preferred discovery mechanism for clients.

This means that removing only the HTML element does not necessarily eliminate REST discovery completely.

You can have:

HTML REST discovery removed

but

HTTP Link header still present

REST API discovery through RSD

WordPress can also advertise the REST API through its older Really Simple Discovery system.

The RSD document may include an entry pointing to:

/wp-json/

This exists mainly for compatibility with clients that already understand RSD or XML-RPC discovery.

See What Is the RSD Tag in WordPress? for that discovery layer.

What does hiding the WordPress REST API mean?

In practical WordPress hardening discussions, hiding the REST API normally means suppressing some or all of its discovery metadata.

For example:

Before

<link
    rel="https://api.w.org/"
    href="https://example.com/wp-json/"
/>


After

REST discovery tag removed

But:

https://example.com/wp-json/

can still work normally.

Hiding does not make the endpoint secret

The default REST API route is predictable.

An automated system can simply request:

/wp-json/

or:

/?rest_route=/

without reading any discovery metadata first.

Therefore:

remove REST discovery
≠
prevent REST requests

This is the same pattern seen with RSD, RSS discovery and WordPress shortlinks.

What does restricting the WordPress REST API mean?

Restricting the REST API means applying rules to actual API requests.

Those rules might require:

• a logged-in WordPress user;
• a valid Application Password;
• a particular WordPress capability;
• a particular role;
• a valid authentication method;
• an allowed network or IP;
• a specific route;
• a custom authorization policy.

The request reaches WordPress, but WordPress determines whether it should be processed.

Hiding vs. restricting: the simplest comparison

Action	Hide REST API	Restrict REST API
Remove HTML discovery link	Yes	Not necessarily
Remove HTTP discovery header	Possibly	Not necessarily
Prevent direct /wp-json/ requests	No	Potentially
Change permissions	No	Yes
Require authentication	No	Yes
Reduce passive discovery	Yes	Not necessarily
Can break REST-dependent functionality	Usually low risk	Potentially high risk

How to hide the REST API link from wp_head

If the objective is only to remove the REST discovery element from the document head, WordPress’s callback can be detached:

remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );

A structured implementation can be:

add_action(
    'after_setup_theme',
    function () {
        remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );
    }
);

This targets HTML discovery only.

It does not disable:

/wp-json/

What about the HTTP REST API Link header?

If you want to suppress REST API discovery more comprehensively, the HTTP Link header should be reviewed separately.

WordPress provides:

rest_output_link_header()

for that discovery mechanism.

Removing one discovery mechanism while leaving another active may still allow compliant clients to find the API automatically.

Should you remove every REST discovery mechanism?

Only if automatic discovery itself provides no value.

Removing discovery can be reasonable when:

• no external client relies on automatic discovery;
• you want cleaner document-head output;
• you want to reduce unnecessary API metadata;
• REST URLs are already explicitly configured in legitimate applications.

But discovery cleanup should not be presented as meaningful access restriction.

How to require authentication for REST API requests

WordPress provides the:

rest_authentication_errors

filter for REST authentication policies.

The official rest_authentication_errors documentation describes this hook as the mechanism through which REST authentication methods can return errors.

The WordPress REST API FAQ also provides an example of requiring users to be authenticated before REST requests are accepted.

A simplified implementation is:

add_filter(
    'rest_authentication_errors',
    function ( $result ) {

        if ( ! empty( $result ) ) {
            return $result;
        }

        if ( ! is_user_logged_in() ) {
            return new WP_Error(
                'rest_not_logged_in',
                'You are not currently logged in.',
                array( 'status' => 401 )
            );
        }

        return $result;
    }
);

This changes actual access behavior.

It is therefore fundamentally different from:

remove_action(
    'wp_head',
    'rest_output_link_wp_head',
    10
);

Why preserve an existing authentication error?

The incoming value passed to rest_authentication_errors may already contain the result of another authentication process.

The official documentation notes that the value can be:

• null when no authentication result has been established;
• true when authentication has succeeded;
• a WP_Error when authentication has failed.

A custom callback should therefore avoid blindly overwriting a previous authentication result.

WordPress does not recommend completely disabling the REST API

Older WordPress code exposed a:

rest_enabled

filter.

That filter has been deprecated since WordPress 4.7.

The official rest_enabled documentation explicitly states that the REST API can no longer be completely disabled through that mechanism and recommends using rest_authentication_errors to restrict access instead.

This reflects the REST API’s increasing importance to WordPress itself.

Why blanket REST API disabling is risky

The REST API is not merely an optional external interface.

Modern WordPress functionality can depend on it internally.

Potential dependencies include:

• Block Editor functionality;
• Site Editor features;
• plugin administration interfaces;
• custom dashboard applications;
• frontend JavaScript;
• headless WordPress applications;
• mobile applications;
• external publishing systems;
• automation platforms;
• WooCommerce or other plugin APIs;
• custom REST endpoints.

Before restricting access globally, see What Depends on the WordPress REST API.

Authentication and authorization are separate layers

REST API security is not simply:

logged in
or
not logged in

There are two related decisions.

Authentication

Authentication determines:

Who is making the request?

Authorization

Authorization determines:

Is that user allowed to perform this operation?

A valid WordPress user account does not automatically grant access to every REST endpoint.

Permission callbacks protect REST endpoints

WordPress REST routes can define a:

permission_callback

The official Routes and Endpoints documentation emphasizes that permission callbacks are critical when an endpoint exposes private information or privileged operations.

A custom endpoint might require:

current_user_can( 'edit_posts' )

before returning its data.

This allows permissions to be enforced at the route level rather than globally shutting down the entire API.

Route-level restriction is often safer than global restriction

Suppose the website needs:

/wp-json/wp/v2/posts

for normal frontend functionality but does not want a custom sensitive namespace publicly available.

The better architecture is:

public posts endpoint
→ leave available

sensitive custom endpoint
→ require permission

entire REST API
→ do not disable

This keeps the security policy aligned with the actual data sensitivity.

Public content can remain public while privileged actions stay protected

A normal public GET request to a posts endpoint can return information that visitors can already see on the website.

But an operation such as:

POST /wp-json/wp/v2/posts

to create content should require authentication and appropriate capabilities.

REST APIs are therefore not simply:

public
or
private

Different HTTP methods and routes can have different permission requirements.

Cookie authentication inside WordPress

For requests originating within WordPress, the REST API supports cookie authentication.

The official REST API Authentication documentation explains that cookie authentication is the standard authentication method for logged-in WordPress users.

WordPress also uses REST nonces to protect these requests against cross-site request forgery.

The nonce is normally associated with:

wp_rest

and can be sent through:

X-WP-Nonce

or the request data.

Why REST nonces matter

A logged-in browser automatically sends WordPress cookies.

Without an additional request token, another website could potentially attempt to trigger requests using those cookies.

The REST nonce helps confirm that the request originated from an authorized WordPress interface.

It is therefore part of the authentication architecture for same-site REST usage.

External REST authentication with Application Passwords

For external applications, WordPress includes Application Passwords.

The official Application Passwords documentation describes them as revocable credentials tied to a specific WordPress user for programmatic access.

They are preferable to giving an external service the user’s normal interactive password.

An external REST request can authenticate using credentials associated with:

username
+
Application Password

Application Passwords do not bypass permissions

An Application Password authenticates as a particular WordPress user.

That user’s capabilities still determine which operations are permitted.

For example:

Application Password for Editor
≠
Administrator permissions

This separation between authentication and authorization should remain intact.

Restricting anonymous REST access

One common policy is:

authenticated requests
→ allowed according to normal permissions

anonymous requests
→ denied

This can reduce public REST exposure while preserving authenticated usage.

However, it can also break functionality that intentionally relies on public API responses.

What can break when anonymous REST access is blocked?

Potential examples include:

• frontend JavaScript retrieving posts;
• headless frontends;
• public search interfaces;
• custom blocks;
• plugin widgets;
• mobile applications;
• external integrations consuming public content;
• third-party services reading public REST data.

That is why authenticated-only REST policies should be tested rather than deployed as generic security folklore.

The Block Editor and REST API restrictions

The WordPress Block Editor communicates extensively through REST endpoints.

The REST API handbook explicitly describes the API as foundational to the Block Editor.

A badly implemented global restriction can therefore produce symptoms such as:

• editor loading errors;
• failed post saves;
• failed block requests;
• missing sidebar data;
• broken plugin panels;
• unexpected REST errors.

A policy that preserves authenticated requests generally has a much better chance of maintaining editor functionality than one that simply rejects every request to:

/wp-json/

REST API restrictions and wp-admin are not identical

It is possible for:

/wp-admin/

to remain accessible while REST-dependent components inside it fail.

Therefore testing only whether the dashboard opens is insufficient.

After changing REST permissions, test actual administrative workflows.

User endpoints receive particular attention

Administrators frequently focus on routes such as:

/wp-json/wp/v2/users

because public user information may expose usernames or author identities depending on site configuration.

That does not necessarily justify disabling the entire REST API.

A more focused policy can restrict specific user-related routes or change how public author information is exposed.

Usernames are not passwords

Publicly discovering an account identifier can assist reconnaissance, but a username is not supposed to function as the secret half of authentication.

The actual security controls should include:

• strong passwords;
• two-factor authentication;
• rate limiting;
• least-privilege accounts;
• monitoring;
• secure Application Password handling.

Hiding REST user information can reduce unnecessary exposure, but it should not substitute for proper authentication security.

Restrict sensitive routes instead of hiding the whole API

If a specific plugin exposes data that should not be public, fix that endpoint’s permissions.

The secure architecture is:

public data
→ public endpoint

authenticated data
→ authentication required

privileged operation
→ authentication + capability check

sensitive endpoint not required
→ remove or disable that route

That is considerably safer than treating every REST route as equally sensitive.

Custom REST endpoints must use permission_callback correctly

When registering a route, developers should define an appropriate:

permission_callback

for protected functionality.

A simplified example is:

register_rest_route(
    'example/v1',
    '/settings',
    array(
        'methods'  => 'GET',
        'callback' => 'example_get_settings',
        'permission_callback' => function () {
            return current_user_can( 'manage_options' );
        },
    )
);

This protects the sensitive endpoint without interfering with unrelated WordPress REST routes.

Do not rely on obscurity for custom endpoints

A custom route such as:

/wp-json/my-secret-plugin/v1/internal-settings

is not secure merely because nobody links to it publicly.

If the endpoint exposes private data, it needs an explicit permission policy.

Hiding its location is supplementary at best.

REST API discovery and API authorization solve different problems

The separation can be summarized as:

Discovery
→ How does a client find the API?

Authentication
→ Who is the client?

Authorization
→ What may that client do?

Removing discovery affects only the first question.

Security-sensitive REST controls primarily belong to the second and third.

Does hiding the REST API improve security?

Only slightly as information-exposure reduction.

Removing:

<link rel="https://api.w.org/" ...>

reduces one passive discovery signal.

But WordPress REST routes are predictable.

A scanner can request:

/wp-json/

directly.

Therefore hiding the REST API should not be described as access control.

Does restricting the REST API improve security?

It can, when the restriction addresses unnecessary exposure.

For example:

• requiring authentication for sensitive custom endpoints;
• restricting privileged operations by capability;
• removing unused routes;
• limiting unnecessary anonymous user information;
• protecting external authentication credentials.

But overly broad restrictions can create reliability problems without providing proportionate security benefits.

Does the REST API expose passwords?

WordPress core does not simply return user passwords through public REST endpoints.

Passwords are not intended to be retrievable in plaintext through WordPress.

Public REST exposure should therefore be evaluated based on the actual endpoint response rather than generalized claims that:

REST API enabled
=
password database exposed

That is not how WordPress REST permissions work.

Does the REST API expose unpublished posts?

Not to arbitrary anonymous users under normal WordPress permission handling.

Private or unpublished content requires appropriate authorization.

An authenticated user may see content according to that user’s WordPress capabilities.

This again demonstrates why permissions are more important than merely hiding the API URL.

Does hiding the REST API help SEO?

There is generally no direct SEO benefit.

The REST discovery link is not the same as:

• a canonical URL;
• an XML sitemap;
• a robots directive;
• structured data;
• internal navigation.

Removing it should normally be treated as technical cleanup rather than search optimization.

Can REST JSON URLs appear in search engines?

Search engines can theoretically encounter URLs through many discovery paths.

If the concern is unnecessary REST URLs appearing in search results, investigate the actual indexed URLs and response behavior rather than assuming that removing the api.w.org discovery link is a complete indexing control.

Discovery cleanup and search indexing policies are separate topics.

Does removing REST discovery improve performance?

The performance impact is negligible.

One small:

<link>

element and an HTTP header do not materially affect Core Web Vitals.

The REST API itself also does not make ordinary frontend pages slow merely by existing.

Performance concerns arise when:

• REST endpoints are called frequently;
• endpoint callbacks are inefficient;
• large datasets are returned;
• plugins perform expensive database queries;
• API traffic is abused.

Restricting API traffic at the edge

CDNs, reverse proxies and web application firewalls can restrict requests before WordPress processes them.

Possible controls include:

• rate limits;
• IP allowlists;
• country restrictions;
• bot protection;
• route-specific rules.

This can be useful for highly targeted external APIs.

However, blocking:

/wp-json/*

indiscriminately at the edge can also block legitimate internal WordPress requests.

REST API rate limiting is different from authentication

A user can be perfectly authorized and still send too many requests.

Likewise, an anonymous endpoint can legitimately be public while still requiring abuse protection.

These controls solve different problems:

Authentication
→ who are you?

Authorization
→ may you do this?

Rate limiting
→ how often may you do it?

Hiding vs. restricting user enumeration

Suppose the concern is author enumeration through REST endpoints.

Removing REST discovery:

does not prevent direct requests

Restricting the relevant user endpoints:

can prevent or reduce direct exposure

But the site may still reveal author identities through:

• author archives;
• post markup;
• structured data;
• feeds;
• public bylines.

Security policies should therefore consider the complete exposure model rather than treating one endpoint as the only source.

Hiding REST discovery does not hide WordPress

The api.w.org link is one WordPress fingerprint.

Removing it can reduce passive identification metadata.

But other WordPress signals can remain:

• /wp-content/;
• /wp-includes/;
• login routes;
• generator metadata;
• RSD;
• XML-RPC;
• theme files;
• plugin assets;
• REST endpoint behavior itself.

See How Attackers Fingerprint WordPress Sites.

REST API vs. XML-RPC

Both allow remote communication with WordPress, but they represent different generations of API architecture.

REST API

• primarily uses JSON;
• uses resource-oriented routes;
• is central to modern WordPress;
• supports modern plugins and applications;
• powers significant editor functionality.

XML-RPC

• uses XML remote procedure calls;
• normally uses xmlrpc.php;
• supports legacy publishing workflows;
• includes WordPress pingback functionality;
• is often unnecessary on modern sites.

See XML-RPC in WordPress, Explained.

Restricting XML-RPC does not restrict REST

The interfaces are independent.

You can configure:

XML-RPC
→ disabled

REST API
→ available

without contradiction.

For many modern websites, that can be more appropriate than disabling both remote interfaces indiscriminately.

How TheOneWP approaches REST API exposure

TheOneWP treats REST discovery and REST access as separate concerns.

If the goal is simply to clean WordPress-generated metadata, REST discovery can be removed without pretending the underlying API has been disabled.

If the requirement is reducing access, permissions and authentication must be considered separately.

The intended distinction is:

Hide REST API links
→ remove unnecessary discovery

Restrict REST API
→ control who can make API requests

Disable unrelated WordPress functionality
→ not automatically required

This avoids using one aggressive global toggle to solve several technically different problems.

When hiding REST discovery makes sense

Hiding can be reasonable when:

• automatic API discovery is unnecessary;
• the site wants cleaner head output;
• REST consumers already know the API URL;
• you want to remove an unnecessary fingerprinting signal;
• you are performing selective WordPress discovery cleanup.

The operational risk is generally much lower than restricting actual API access.

When REST restriction makes sense

Restriction can be appropriate when:

• an endpoint exposes data that should require authentication;
• anonymous access is unnecessary;
• a custom application should be the only consumer;
• a sensitive plugin route lacks appropriate exposure controls;
• API abuse is creating resource usage;
• specific account information should not be public;
• external API access should be limited to known users or systems.

When not to apply a global REST restriction

A blanket restriction deserves caution when the site uses:

• Gutenberg;
• the Site Editor;
• WooCommerce;
• headless frontend technology;
• frontend blocks that retrieve REST data;
• mobile apps;
• JavaScript applications;
• external automation;
• custom plugin interfaces.

In these cases, route-specific permissions are often a better solution.

A safer REST API restriction strategy

Instead of beginning with:

Block everything

use a layered process.

1. Inventory routes

Understand which core and plugin routes exist.

2. Identify public requirements

Determine which endpoints intentionally serve public content.

3. Identify sensitive endpoints

Look for:

• user data;
• private settings;
• internal application state;
• privileged actions;
• custom plugin endpoints.

4. Verify permission callbacks

Protected routes should enforce capabilities correctly.

5. Restrict only what is unnecessary

Apply authentication or route-level restrictions to those endpoints.

6. Add abuse controls separately

Use rate limiting, WAF policies or other traffic controls where appropriate.

How to audit your WordPress REST API

Check the API root

Visit:

https://example.com/wp-json/

The root index can reveal registered namespaces and available route information.

Check default permalink fallback

On configurations without pretty permalinks, REST access can use:

/?rest_route=/

Blocking only the visible:

/wp-json/

path may therefore not represent a complete application-level restriction.

Check the document head

Search for:

https://api.w.org/

Check HTTP response headers

Look for:

Link: <.../wp-json/>; rel="https://api.w.org/"

Check RSD

If RSD remains active, determine whether it advertises the REST API as well.

Review registered namespaces

The REST root can reveal namespaces introduced by plugins and custom code.

Test anonymous requests

Determine which information is available without authentication.

Test authenticated requests

Verify capabilities are enforced correctly.

How to test after hiding REST discovery

After removing discovery:

1. clear WordPress caches;
2. clear CDN caches;
3. inspect the rendered HTML;
4. inspect response headers;
5. check RSD if applicable;
6. request /wp-json/ directly;
7. confirm REST-dependent functionality still works.

If direct REST access still works, that is expected when you have only hidden discovery.

How to test after restricting REST access

This requires a broader test plan.

Test logged-out visitors

Verify intentionally public functionality.

Test wp-admin

Check normal dashboard screens.

Test the Block Editor

Create and update a draft.

Test the Site Editor

If the theme uses it, confirm it can retrieve and save data.

Test plugins

Check plugin screens that use JavaScript-heavy interfaces.

Test frontend functionality

Verify blocks, filters, searches or applications that retrieve data dynamically.

Test external integrations

Check Application Passwords, mobile applications, automations and custom clients.

Check logs

Look for unexpected:

401
403

responses to legitimate REST traffic.

Common mistakes when hiding or restricting the REST API

Removing api.w.org and assuming the API is disabled

The endpoint normally remains directly accessible.

Blocking /wp-json/ only

The REST API can also use:

?rest_route=

routing depending on permalink configuration.

Using the deprecated rest_enabled filter

Modern WordPress recommends access restrictions through authentication mechanisms instead.

Requiring authentication for every request without testing

This can break legitimate public functionality.

Blocking the entire API to protect one endpoint

Fix that endpoint’s permission model instead.

Assuming authentication alone is sufficient

An authenticated user still requires authorization for privileged actions.

Registering sensitive custom routes with weak permissions

Every sensitive endpoint needs a meaningful permission_callback.

Relying on a secret REST URL

Security through obscurity is not authorization.

Assuming the REST API exposes every WordPress database field

Responses are controlled by registered REST schemas, controllers and permissions.

Blocking REST to prevent WordPress fingerprinting

WordPress remains detectable through many other signals.

Calling every public REST response a privacy leak

Public content is often intentionally exposed through both HTML and JSON.

Restricting REST and testing only the homepage

The breakage often appears inside administrative or JavaScript-driven workflows instead.

WordPress REST API hiding and restriction checklist

• Understand that REST discovery and REST access are different layers.
• Know that the main REST API root is normally /wp-json/.
• Remember that ?rest_route=/ may also provide REST routing.
• Inspect the api.w.org link in the document head.
• Inspect the REST API HTTP Link header.
• Review RSD-based REST discovery.
• Remove rest_output_link_wp_head only when HTML discovery is unnecessary.
• Understand that removing discovery does not disable the API.
• Do not use discovery removal as access control.
• Do not rely on obscurity for REST security.
• Understand the difference between authentication and authorization.
• Review rest_authentication_errors for global authentication policies.
• Preserve existing authentication results when using the filter.
• Know that the old rest_enabled filter is deprecated.
• Do not blindly disable modern WordPress REST functionality.
• Check Block Editor dependencies.
• Check Site Editor dependencies.
• Check plugin REST dependencies.
• Check frontend JavaScript dependencies.
• Check headless frontend dependencies.
• Check mobile applications.
• Check external automations.
• Use Application Passwords where appropriate for external authentication.
• Keep Application Passwords separate from normal interactive passwords.
• Review custom route permission_callback implementations.
• Require appropriate capabilities for privileged endpoints.
• Restrict specific routes instead of the entire API where possible.
• Review public user endpoint exposure independently.
• Do not treat usernames as passwords.
• Use strong authentication and 2FA for actual account protection.
• Use rate limiting separately from authentication.
• Use WAF rules carefully.
• Do not block all /wp-json/ traffic at the edge without testing.
• Audit registered REST namespaces.
• Test anonymous requests.
• Test authenticated requests.
• Test multiple user roles.
• Test REST-dependent wp-admin functionality.
• Test the Block Editor after restrictions.
• Test external integrations.
• Inspect 401 and 403 responses after deployment.
• Do not describe REST discovery cleanup as significant performance optimization.
• Do not assume hiding REST makes WordPress anonymous.
• Document which REST routes are intentionally public.
• Document which routes require authentication.
• Keep the restriction policy as narrow as the actual security requirement.

Related guides

• How WordPress Advertises Its REST API
• WordPress REST API Security Basics
• What Depends on the WordPress REST API
• WordPress Head Tags You Can Safely Remove
• XML-RPC in WordPress, Explained

Final recommendation

Hiding the WordPress REST API is primarily a discovery and cleanup decision.

Restricting the REST API is an authentication and authorization decision.

They should not be treated as interchangeable security controls.

If the only objective is removing unnecessary metadata, you can suppress the REST API discovery links from the page head and, if appropriate, the HTTP response headers while leaving the API functional.

This removes passive discovery but does not prevent anyone from directly requesting known REST routes.

If the objective is protecting sensitive information or privileged operations, focus on permissions instead.

Use authentication where anonymous access is unnecessary, capability checks where only particular users should perform an action, and route-specific policies where only part of the API needs restriction.

Avoid globally blocking the REST API simply because /wp-json/ is publicly reachable.

Public REST access to public content is a normal part of WordPress architecture, and modern WordPress components frequently depend on REST internally.

The safest strategy is therefore selective:

Unnecessary discovery
→ hide it

Public content intentionally exposed
→ leave it public

Sensitive data
→ require authentication and permissions

Unused custom endpoint
→ remove or restrict it

Abusive traffic
→ rate-limit it

Entire REST API
→ preserve unless you have verified that broad restriction is truly appropriate

That keeps the security policy focused on actual access rather than on whether an API URL happens to be visible.