What is the WordPress shortlink, and do you need it?

WordPress can give the same published post more than one valid way to reach it.

A modern site might display a readable permalink such as:

https://example.com/guides/wordpress-security/

while WordPress can also generate a much shorter address based on the post ID:

https://example.com/?p=1234

That second address is the WordPress shortlink.

Shortlinks were introduced as a stable, compact way to reference WordPress content without depending on the site’s current permalink structure. WordPress can advertise the shortlink in the document <head>, expose it through an HTTP Link header and return it programmatically through its shortlink API.

For many modern WordPress websites, however, the shortlink provides little practical value. Readable permalinks are better for users, easier to understand when shared, and normally serve as the preferred URL for search engines and internal navigation.

That does not automatically make the shortlink harmful.

The important distinction is this: a WordPress shortlink is an alternative reference to a piece of content, not normally the page’s preferred canonical URL.

You can therefore keep it, remove its public discovery markup, customize it through code or a plugin, or remove the shortlink tag and HTTP header while allowing the underlying ?p=ID address to continue resolving.

This guide explains what WordPress shortlinks are, how they work, how they differ from permalinks and canonical URLs, whether they affect SEO or security, and when removing them makes sense.

What is a WordPress shortlink?

A WordPress shortlink is a compact URL that identifies published content primarily through its numeric WordPress post ID.

For example, suppose a post has the following normal permalink:

https://example.com/how-to-secure-wordpress-login/

and its WordPress post ID is 587.

WordPress can generate the following shortlink:

https://example.com/?p=587

The official wp_get_shortlink() documentation describes the function used to retrieve a shortlink for WordPress content.

By default, public post types can use the familiar ?p=ID structure.

The important part is the numeric ID.

WordPress does not need the post title or public slug to identify the content. It can use the stored post ID to determine which object was requested.

Why does WordPress have shortlinks?

The feature makes more sense when viewed in the context in which it was introduced.

Long human-readable URLs are excellent for visitors and search engines, but they can change when a website restructures its permalink format.

A numeric post ID, by contrast, normally remains attached to the same database object.

Consider this post:

https://example.com/2019/04/wordpress-security-guide/

If the site later changes its permalink structure, the public permalink might become:

https://example.com/guides/wordpress-security-guide/

The post ID could still remain:

1234

and therefore the shortlink could remain:

https://example.com/?p=1234

This makes the shortlink a compact identifier that is less closely coupled to the site’s pretty-permalink structure.

WordPress also designed its shortlink API so plugins could provide different short URL implementations instead of being permanently restricted to ?p=ID.

How WordPress generates a shortlink

The central WordPress function is wp_get_shortlink().

A simple PHP example is:

$shortlink = wp_get_shortlink();

echo esc_url( $shortlink );

For an ordinary public post, WordPress may return something similar to:

https://example.com/?p=1234

The function can also receive a specific content ID:

$shortlink = wp_get_shortlink( 1234 );

WordPress exposes filters around this process, including pre_get_shortlink and get_shortlink, allowing plugins or custom implementations to replace or modify the default short URL.

This is an important design detail.

A WordPress shortlink does not have to be ?p=1234. That is simply the default core implementation when another system has not replaced it.

Where does WordPress expose the shortlink?

The shortlink is not limited to a URL you can manually generate in PHP.

WordPress can expose it in several places.

The document head

The core wp_shortlink_wp_head() function can output a shortlink element inside the document <head>.

It typically looks like this:

<link rel="shortlink" href="https://example.com/?p=1234" />

The element identifies an alternative short reference for the current resource.

The HTTP response headers

WordPress can also advertise the shortlink through the wp_shortlink_header() function.

At the HTTP level, the response can include a Link header representing the same shortlink relationship.

This means inspecting only the HTML source is not enough when verifying whether WordPress shortlink discovery has been fully removed.

A cleanup implementation that removes:

<link rel="shortlink" ...>

but leaves the HTTP header active has removed only one of the two public discovery mechanisms.

WordPress PHP functions

Developers can retrieve the URL through wp_get_shortlink() or display it through WordPress’s the_shortlink() function.

The shortlink system therefore exists independently of whether the site’s theme visibly prints a short URL for users.

Shortlink vs. permalink: what is the difference?

The terms sound similar but represent different concepts.

A permalink is the normal public URL

A permalink is the URL WordPress normally presents for a post, page or another public content object.

For example:

https://example.com/wordpress-security-guide/

The permalink usually reflects the site’s configured URL structure and may contain:

• the post slug;
• category information;
• dates;
• custom post type bases;
• other rewrite components.

It is normally the URL you want people, navigation systems, sitemaps and search engines to use.

A shortlink is an alternative compact reference

The default WordPress shortlink might instead be:

https://example.com/?p=1234

It identifies the same underlying post using its ID.

The shortlink is therefore not a replacement for the site’s normal permalink structure.

If you are restructuring public URLs, see How to Migrate WordPress URLs Safely. Changing a public permalink structure is an actual URL migration and requires different planning from simply removing shortlink discovery.

Shortlink vs. canonical URL

This distinction matters much more for SEO.

A shortlink and a canonical URL can both point toward the same underlying content, but they communicate different ideas.

The shortlink says “here is a compact reference”

For example:

<link
    rel="shortlink"
    href="https://example.com/?p=1234"
/>

The canonical says “this is the preferred URL”

The same page may contain:

<link
    rel="canonical"
    href="https://example.com/wordpress-security-guide/"
/>

The canonical URL is the relevant signal when telling search engines which URL should represent duplicate or substantially similar variants.

The shortlink should not be treated as a replacement for canonicalization.

If a site has several accessible URL variations, your canonical configuration should identify the preferred clean URL consistently.

See WordPress Canonical URLs, Explained for the full relationship between canonical tags, duplicate URLs, redirects, sitemaps and internal links.

Does the ?p=ID WordPress URL still work with pretty permalinks?

In many ordinary WordPress configurations, the numeric query-style URL can still identify a post even when pretty permalinks are enabled.

For example:

https://example.com/?p=1234

may identify the same content whose normal permalink is:

https://example.com/guides/wordpress-security/

WordPress also contains canonical redirect logic that can normalize certain alternative requests toward their proper permalink.

The official redirect_canonical() documentation describes WordPress’s canonical URL correction logic.

The exact response should still be tested on the actual installation because plugins, routing changes, caching layers and custom rewrite behavior can modify the result.

Does removing the shortlink disable ?p=ID URLs?

No. Not necessarily.

This is one of the most important distinctions in the entire feature.

You can remove:

<link rel="shortlink" href="..." />

and the corresponding HTTP discovery header without disabling WordPress’s ability to interpret a URL such as:

https://example.com/?p=1234

The first change removes advertisement of the shortlink.

The second would require changing or blocking routing behavior.

They are separate concerns.

This is the same architectural distinction that appears elsewhere in WordPress. Removing REST API discovery does not automatically disable the REST API, removing RSS discovery does not automatically disable feed endpoints, and removing RSD markup does not automatically disable XML-RPC.

For the wider pattern, see Cleaning Up WordPress’s Default Head Output.

Do WordPress shortlinks cause duplicate content?

The existence of another URL that can resolve to the same content is worth understanding, but it should not automatically be described as an SEO disaster.

Search engines routinely encounter alternative URLs, parameters and redirects.

What matters is whether the site’s signals consistently identify the intended primary URL.

For a normal public post, those signals can include:

• canonical tags;
• redirect behavior;
• XML sitemap URLs;
• internal links;
• external links;
• server responses;
• consistent permalink usage.

If the normal permalink is clearly canonical and alternative forms consolidate appropriately, the presence of an underlying ?p=ID route does not automatically mean search engines will treat both addresses as independent competing pages.

The practical SEO objective is URL consistency, not the elimination of every technically reachable variation.

Should you use WordPress shortlinks for internal links?

Normally, no.

Internal links should generally point directly to the site’s preferred permanent URL.

Instead of:

<a href="https://example.com/?p=1234">
    WordPress security guide
</a>

prefer:

<a href="https://example.com/wordpress-security-guide/">
    WordPress security guide
</a>

This keeps the site’s internal URL signals consistent and provides visitors with understandable destinations.

It also avoids depending on an alternative URL that may redirect before reaching the final public permalink.

The same principle applies after URL migrations. Internal links should be updated to point directly to the new destination instead of relying permanently on redirects.

Should shortlinks appear in XML sitemaps?

Normally, no.

An XML sitemap should list the URLs you actually want search engines to crawl and treat as the primary published locations of your content.

If:

https://example.com/wordpress-security-guide/

is the canonical public URL, that is normally the URL that belongs in the sitemap.

The shortlink:

https://example.com/?p=1234

does not need to be submitted as an additional sitemap entry merely because WordPress can resolve it.

For sitemap architecture, see What Is an XML Sitemap and Why Does It Matter?.

Are WordPress shortlinks useful today?

They can be, but their usefulness is much narrower than it once was.

They provide a stable ID-based reference

The post ID usually remains stable even if the pretty permalink changes.

This can make a shortlink useful in certain internal systems, custom integrations or developer workflows where content is identified primarily by WordPress IDs.

Plugins can replace the default implementation

The WordPress shortlink API was deliberately designed so another system can return a custom short URL.

A plugin could theoretically convert:

https://example.com/?p=1234

into something such as:

https://exm.pl/aB32k

or another site-specific format.

In that situation, the shortlink feature may have a deliberate product or sharing purpose.

Legacy integrations may rely on it

An older publishing workflow, external application or custom theme can potentially call WordPress’s shortlink functions.

Removing public discovery is normally less disruptive than removing the underlying API behavior, but compatibility should still be checked on sites with custom integrations.

Why might you remove the WordPress shortlink?

For many modern sites, there is no actual requirement for public shortlink discovery.

The normal permalink is already shareable

Readable URLs are usually preferable in emails, documentation, social posts and internal navigation because they communicate what the destination contains.

Compare:

https://example.com/wordpress-backup-guide/

with:

https://example.com/?p=4827

The first URL provides immediate context. The second provides only a numeric identifier.

It removes unnecessary head output

If no application uses shortlink discovery, removing the tag makes the document head slightly more intentional.

The data saving is tiny and should not be treated as a serious performance optimization.

The benefit is configuration hygiene rather than meaningful page-speed improvement.

It removes an unnecessary public WordPress signal

The ?p=ID format and rel="shortlink" markup are recognizable WordPress characteristics.

Removing them can eliminate one easy fingerprinting signal.

This does not hide the fact that a website uses WordPress.

Attackers can inspect asset paths, REST behavior, login endpoints, plugin resources, themes, generator data and many other indicators.

For the full picture, see How Attackers Fingerprint WordPress Sites.

It reduces URL ambiguity for site administrators

Removing public advertisement of an unused alternative URL can make technical audits easier to interpret.

You still need to understand that the underlying ?p=ID route may exist, but the page no longer explicitly promotes it as another relationship in HTML and HTTP metadata.

Does removing WordPress shortlinks improve performance?

Only by an extremely small amount if you are removing the discovery markup alone.

A shortlink tag contains very little HTML:

<link rel="shortlink" href="https://example.com/?p=1234" />

Removing it is not going to transform Core Web Vitals, reduce a multi-second Largest Contentful Paint or solve an overloaded database.

The HTTP header is similarly small.

Shortlink removal should therefore be classified as cleanup, not serious performance optimization.

Real WordPress performance work usually involves much larger factors such as:

• render-blocking assets;
• JavaScript execution;
• image delivery;
• font loading;
• page caching;
• object caching;
• database queries;
• third-party scripts;
• hosting and server configuration.

Does removing the shortlink improve WordPress security?

Only in a limited disclosure sense.

A shortlink can reveal:

• that the site behaves like WordPress;
• a numeric post ID;
• an alternative public route to content.

Removing it can reduce those particular clues.

It does not:

• patch a WordPress vulnerability;
• protect administrator accounts;
• prevent brute-force attacks;
• disable REST API access;
• disable XML-RPC;
• hide plugin and theme assets;
• stop vulnerable software from being exploited;
• make WordPress impossible to fingerprint.

Shortlink cleanup is therefore a small hardening and disclosure-reduction measure, not a security boundary.

See Why Hide Your WordPress Version Number? for a similar distinction between reducing unnecessary disclosure and actually fixing vulnerabilities.

Does the numeric post ID itself create a security risk?

A public post ID should not normally be treated as a secret.

WordPress uses numeric IDs throughout its data model, and public content may expose them through multiple mechanisms depending on the site’s configuration.

Knowing that a public post has ID 1234 does not grant permission to edit it, bypass authentication or access private content.

Authorization still depends on WordPress authentication and capability checks.

Sequential identifiers can sometimes assist reconnaissance by giving an observer structural information, but hiding IDs should not be mistaken for access control.

Sensitive resources must remain protected even when their identifiers are known.

How to check whether your site outputs a shortlink

There are several ways to audit the current behavior.

Inspect the HTML source

Open a single published post or page and inspect its rendered source.

Search for:

rel="shortlink"

You may find something similar to:

<link rel="shortlink" href="https://example.com/?p=1234" />

Inspect HTTP headers

The HTML check is only half of the audit.

You can inspect the response headers using browser developer tools or a command such as:

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

Review any Link headers for a rel="shortlink" relationship.

Test the ?p=ID URL

Once you know the post ID, request:

https://example.com/?p=1234

and observe what the site does.

It might:

• load the requested content;
• redirect to the pretty permalink;
• behave differently because of custom routing or plugins.

Do not assume the behavior from the presence or absence of the head tag. Test the actual route.

How to remove the WordPress shortlink safely

WordPress exposes the relevant behavior through hooks, so there is no reason to modify core files.

The official remove_action() documentation explains how callbacks registered on WordPress hooks can be removed when the callback and priority match the original registration.

A focused implementation can remove both public discovery layers:

add_action(
    'after_setup_theme',
    function () {
        remove_action( 'wp_head', 'wp_shortlink_wp_head', 10 );
        remove_action( 'template_redirect', 'wp_shortlink_header', 11 );
    }
);

The first line removes the shortlink element from the document head.

The second removes the shortlink HTTP header.

This is deliberately narrower than trying to block every ?p=ID request.

The site’s ordinary permalink system remains separate.

Why remove both callbacks?

If you remove only:

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

the HTML may look clean while WordPress can still advertise the shortlink in its response headers.

Likewise, removing only the header does not remove the HTML element.

If the objective is to stop publicly advertising shortlinks, both locations deserve attention.

Do not edit WordPress core

Do not delete shortlink functions from wp-includes or modify WordPress’s default hook registrations directly inside core files.

Core updates can overwrite those changes, and modifying core creates unnecessary maintenance problems.

Use a maintained plugin, a must-use plugin or a controlled project-specific customization layer instead.

Should you block ?p=ID URLs completely?

Usually, removing public shortlink discovery is enough if the only objective is cleanup.

Blocking the underlying ?p=ID route is a different decision and can introduce unnecessary complexity.

The query-style URL may still be useful for:

• old links;
• external references;
• legacy integrations;
• WordPress compatibility;
• custom application logic.

If the URL currently redirects cleanly to the preferred permalink, allowing that behavior may be preferable to returning an error simply because the alternative syntax exists.

The larger SEO question is whether requests consolidate toward the correct final URL.

For moved or obsolete URLs that genuinely require explicit redirect rules, see 301 vs. 302 vs. 410: Which Redirect to Use?.

What happens if you change your permalink structure?

The shortlink and public permalink are based on different pieces of information.

Suppose a post has ID 1234 and currently lives at:

https://example.com/2026/wordpress-security/

You later change the structure to:

https://example.com/guides/wordpress-security/

The default shortlink can still be based on:

https://example.com/?p=1234

because the underlying post ID has not changed.

This illustrates why shortlinks can function as relatively stable references.

It does not mean they should replace a proper URL migration strategy.

Changing the public permalink still requires you to consider:

• redirects;
• internal links;
• external backlinks;
• canonical URLs;
• XML sitemaps;
• analytics;
• search indexing;
• cached URLs.

A numeric fallback URL cannot solve those migration responsibilities for you.

Can plugins customize WordPress shortlinks?

Yes.

WordPress provides filters specifically for this purpose.

The pre_get_shortlink filter can short-circuit WordPress’s own shortlink generation, while get_shortlink can modify the generated result.

A simplified example could look like:

add_filter(
    'pre_get_shortlink',
    function ( $shortlink, $id, $context, $allow_slugs ) {
        if ( ! $id ) {
            return $shortlink;
        }

        return home_url( '/s/' . $id );
    },
    10,
    4
);

This is merely an architectural example.

A real custom short URL system would also need routing, validation, collision handling and appropriate redirect behavior.

Do not create a custom shortlink format merely because WordPress allows it. Build one only if the site has an actual requirement for short URL generation.

Shortlinks and custom post types

WordPress’s default shortlink implementation can work with public post types.

That means a public custom post type can participate in the same general mechanism.

Suppose a project has a public course post type:

https://example.com/courses/wordpress-security/

with post ID 8132.

An ID-based shortlink can identify the same object through:

https://example.com/?p=8132

The public custom post type permalink should still normally remain the URL used for navigation, canonicalization and XML sitemaps.

For the broader relationship between custom post types, archives, URLs and metadata, see WordPress Custom Post Types and SEO.

Shortlinks on the static front page

WordPress contains special handling for the site itself and for content used as the front page.

The practical lesson is that developers should not assume every WordPress request will produce the same ?p=ID shortlink pattern.

Context, post type, configuration and filters can influence the returned short URL.

If you are auditing shortlink behavior, test the actual content types and templates used by the project instead of inspecting one post and assuming the result applies everywhere.

WordPress shortlinks and redirects

Shortlinks and redirects are also separate concepts.

A shortlink identifies another address for content.

A redirect tells a browser or crawler to request a different URL.

For example:

Request:
https://example.com/?p=1234

Response:
301 or another redirect

Location:
https://example.com/wordpress-security-guide/

In this case the short query-style URL is an incoming route, while the redirect controls what happens after it is requested.

That is different from the head element:

<link rel="shortlink" href="https://example.com/?p=1234" />

which merely advertises the alternative relationship.

Understanding these layers prevents a common maintenance mistake: removing one piece of metadata and assuming the server’s routing behavior has also changed.

WordPress shortlinks and canonical redirects

WordPress contains canonical redirect functionality intended to normalize requests when it can determine a more appropriate URL.

This is useful because visitors can arrive through many forms of a URL:

• query-style URLs;
• old permalink variations;
• incorrect capitalization or structure in some configurations;
• attachment or feed variations;
• other request patterns WordPress can normalize.

Shortlink removal should not interfere with that system.

If ?p=1234 currently reaches or redirects to the correct public permalink, removing shortlink discovery usually does not require changing that behavior.

How shortlinks relate to URL migrations

Shortlinks can survive permalink changes because the numeric post ID can remain stable, but that does not make them a migration strategy.

Suppose a website changes:

/blog/wordpress-security/

to:

/guides/wordpress-security/

The correct migration process still requires the old public URL to be handled appropriately.

A shortlink such as:

/?p=1234

does not preserve backlinks that point to:

/blog/wordpress-security/

Those backlinks still request the old pretty permalink.

You therefore need appropriate redirects between the old and new public URLs.

See How to Migrate WordPress URLs Safely for the complete process.

How TheOneWP handles WordPress shortlinks

TheOneWP provides a focused Disable Shortlink module for sites that do not need WordPress’s public shortlink discovery.

The module removes both:

• the rel="shortlink" element from the document head;
• the corresponding WordPress shortlink HTTP header.

It deliberately does not attempt to break the standard ?p=ID route.

This distinction keeps the change narrow.

The public page stops advertising the unnecessary shortlink relationship, while existing ID-based WordPress routing remains available for compatibility.

This follows the same modular philosophy used by other TheOneWP cleanup features: remove the output you do not need without disabling unrelated functionality merely because both features happen to be connected internally.

How to test after disabling WordPress shortlinks

Do not assume the feature is gone simply because you cannot see anything obvious on the page.

Check the rendered head

Inspect the HTML source and confirm that:

rel="shortlink"

is no longer present.

Check response headers

Inspect the HTTP response and verify that the shortlink relationship is no longer being advertised through a Link header.

Test the normal permalink

Confirm that the intended public URL still returns the expected content and status code.

Test ?p=ID separately

If your objective was discovery cleanup rather than complete route removal, verify that:

https://example.com/?p=1234

still behaves as expected.

Check canonical output

Confirm that the canonical URL still identifies the preferred public permalink.

For example:

<link
    rel="canonical"
    href="https://example.com/wordpress-security-guide/"
/>

Shortlink cleanup should not remove or replace canonical metadata.

Check the XML sitemap

Verify that the sitemap contains the preferred public URL rather than unnecessary shortlink variations.

Check internal links

Crawl representative content and confirm that internal navigation points directly to the preferred permalink.

If your own site repeatedly links through ?p=ID URLs, update those references instead of relying on redirects indefinitely.

Clear caches

A page cache, server cache or CDN can continue serving old HTML and headers after you change WordPress hooks.

Purge the appropriate layers before judging the final result.

Common WordPress shortlink mistakes

Confusing the shortlink with the canonical URL

The two relationships are not interchangeable.

The canonical identifies a preferred representative URL. The shortlink provides a compact alternative reference.

Removing only the HTML element

WordPress can advertise shortlinks through HTTP headers as well.

A complete discovery cleanup checks both.

Trying to remove every ?p=ID route

Removing discovery markup does not require breaking ID-based routing.

Do not solve a problem the site does not actually have.

Treating shortlink removal as major performance optimization

The amount of markup removed is tiny.

Use the feature for cleanliness and deliberate configuration, not as a substitute for actual performance work.

Treating it as a serious security control

Shortlink removal reduces one disclosure signal.

It does not replace updates, strong authentication, permissions, hardening, monitoring or vulnerability remediation.

Using shortlinks throughout internal content

Internal links should normally point directly to canonical public URLs.

Do not create an unnecessary layer of alternative URLs or redirects within your own site architecture.

Blocking a working compatibility route without testing

A site may have historic references, integrations or custom code that still use ID-based URLs.

If there is no clear reason to reject those requests, preserving normal routing while removing public discovery is often the safer approach.

Do you actually need WordPress shortlinks?

For a typical modern WordPress website, probably not.

If your site:

• uses readable pretty permalinks;
• does not provide a custom URL-shortening service;
• has no integration relying on WordPress shortlink discovery;
• uses normal canonical URLs;
• links internally to its public permalinks;

then the default shortlink element and header are usually optional.

Removing them is a reasonable cleanup decision.

There are still cases where keeping shortlinks makes sense.

Keep or customize them when:

• a plugin provides a meaningful short URL service;
• an external publishing system relies on the WordPress shortlink API;
• a custom application uses shortlinks intentionally;
• the feature serves an actual editorial or sharing workflow.

The correct decision is based on functionality, not on whether a line of HTML looks old.

WordPress shortlink checklist

• Understand that a WordPress shortlink is an alternative compact URL.
• Know that the default format for public content is commonly ?p=ID.
• Do not confuse the shortlink with the normal permalink.
• Do not confuse rel="shortlink" with rel="canonical".
• Use the normal public permalink for internal linking.
• Use canonical URLs consistently for search engines.
• Submit canonical public URLs rather than shortlinks in XML sitemaps.
• Check whether the theme or plugins actually use shortlinks before removing them.
• Inspect the document head for rel="shortlink".
• Inspect HTTP response headers for shortlink discovery.
• Remember that removing the head element does not automatically remove the HTTP header.
• Remember that removing discovery does not automatically disable ?p=ID routing.
• Do not modify WordPress core files to remove shortlinks.
• Use hooks or a maintained plugin instead.
• Do not describe shortlink removal as a major performance optimization.
• Do not describe it as a substitute for WordPress security controls.
• Test normal permalinks after changing shortlink behavior.
• Test ID-based URLs separately when compatibility matters.
• Verify canonical metadata after cleanup.
• Verify XML sitemap URLs.
• Check internal links for unnecessary shortlink usage.
• Clear page, server and CDN caches before testing.
• Document the decision so future developers know why shortlinks are absent.

Related guides

• Cleaning Up WordPress’s Default Head Output
• WordPress Canonical URLs, Explained
• How to Migrate WordPress URLs Safely
• 301 vs. 302 vs. 410: Which Redirect to Use?
• HTTP Status Codes for WordPress Sites, Explained
• What Is an XML Sitemap and Why Does It Matter?
• WordPress Custom Post Types and SEO
• How Attackers Fingerprint WordPress Sites
• Why Hide Your WordPress Version Number?
• WordPress REST API Security Basics

Final recommendation

The WordPress shortlink is a compact alternative URL that normally identifies public content through its numeric post ID.

It exists independently of the readable permalink most visitors see.

For a typical post, WordPress might therefore understand both:

https://example.com/wordpress-security-guide/

https://example.com/?p=1234

The first should normally be treated as the public permalink and preferred URL. The second is simply another way WordPress can identify the same underlying content.

For most modern websites, there is little reason to advertise that shortlink publicly unless a plugin, external integration or deliberate sharing workflow uses it.

Removing the shortlink element and corresponding HTTP header is therefore reasonable configuration cleanup.

Do not confuse that cleanup with disabling WordPress’s underlying ?p=ID routing. The two changes solve different problems, and there is rarely a reason to break a working compatibility route merely because you no longer want WordPress to advertise it.

Likewise, do not expect shortlink removal to deliver meaningful performance gains or major security protection. It removes a tiny amount of metadata and one recognizable WordPress signal.

Keep your readable permalink as the URL used for internal links, canonical metadata, XML sitemaps and normal sharing. Let redirects and WordPress routing handle legitimate alternative requests when necessary.

If no system actually needs shortlink discovery, remove the head element and HTTP header and leave the rest of WordPress alone.

The goal is not to make every alternative URL impossible. The goal is to make the preferred URL obvious, consistent and intentional everywhere that matters.