Should internal links in WordPress be absolute or relative?

The three forms

When you search for a post in the block editor's link control and select it, WordPress inserts the full permalink: scheme, host and path. The same goes for images, which are inserted with the full address of the file in uploads. That text is saved in the post content as it stands. WordPress does not rewrite it later; if the post's slug changes, links to it elsewhere in your content keep the old address.

You can type a root-relative address by hand and the editor will accept it. Document-relative links are the one form to avoid outright: with pretty permalinks the same content appears at different depths, so ../espresso/ points to different places from a post, an archive and the feed.

What search engines do with each

Google's link guidelines require an <a> element with an href it can resolve, and it resolves relative URLs against the page's address in the standard way. A root-relative internal link is crawled and counted like an absolute one. There is no ranking difference.

The differences are in what can go wrong:

• Host and scheme variants. A root-relative link inherits whatever host the page was loaded on. If your site answers on both www and non-www, or on http, every relative link on the wrong variant leads to another wrong-variant page, and a crawler can wander through a full duplicate of the site. Absolute links always point at the right host. A proper redirect to one host fixes this at the source, and you should have that regardless.
• Content outside the site. Feeds, email newsletters, feed readers and scrapers show your content on another host. Root-relative links then resolve against that host and break. With absolute links, a scraped copy of your article still links back to you.
• Staging and migration. Here relative links have the advantage, since they follow the site to a new domain.

The domain-change cost, and how to pay it

The one real drawback of absolute links is that they hard-code the domain into thousands of posts. Move from old.example to new.example, or from http to https, and the stored links still say the old address. Redirects will carry visitors across, but every internal link then takes an extra hop until you fix them.

The fix is a single, well-understood operation. With WP-CLI:

wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid --dry-run

Remove --dry-run once the count looks right. The command handles serialized data, which a raw SQL replace does not. Our guide to moving WordPress to a new domain puts this in sequence with redirects and Search Console.

Because that fix is cheap and rare, it does not justify relative links everywhere.

Practical rules

1. Let the link control do it. Search for the target and select it; you get the current, canonical address.
2. Link to the final URL. Not an http version, not a redirected old slug, not a ?p= short form. Each of those works through a redirect.
3. Match your canonical host and trailing slash. If the site's addresses end in a slash, so should your links.
4. Never link to staging or localhost. After a launch, search the content for the staging host name; leftover links are one of the most common post-migration faults.
5. Fix links after changing a slug. Redirects are a safety net, not a substitute for updating the source.
6. In theme and plugin code, generate URLs with functions such as home_url() and get_permalink() instead of typing either form, so they are always correct for the current site.

One tool note: Hydrogen SEO's internal link counter reads links saved in content and treats full addresses on your domain, with or without www, as internal. It skips relative paths, so links written that way are not reflected in a post's counts or in the Orphaned filter. That is another reason to keep to absolute links.