Bitnami WordPress images ship with this in wp-config.php:
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);It is there so the stack works on any hostname out of the box, which is reasonable for a fresh image and quietly destructive on a production site.
WordPress now derives its own address from whatever Host header arrives. Hit the server on its raw IP and WordPress believes it lives on that IP.
How it becomes a search problem
Yoast caches one permalink per object in wp_yoast_indexable. Whichever hostname was present when a row was first built gets frozen into it, permanently.
Any bot, uptime monitor or curious person hitting the EC2 IP, the CloudFront domain or the www host causes Yoast to build rows with that hostname. Those become your canonical tags.
On one site we audited, 33 of 70 pages carried canonicals like this:
<link rel="canonical" href="http://63.177.116.175:80/services/..." />Every affected page was a money page. You are telling Google the authoritative version of your service page lives on a bare IP address.
Detecting it
Straight from the database:
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(permalink, '/', 3), '//', -1) AS host,
COUNT(*)
FROM wp_yoast_indexable
WHERE permalink IS NOT NULL AND permalink <> ''
GROUP BY host;Anything other than your canonical hostname is a problem. Expect to find the server IP, the cloud provider’s internal DNS name, a CDN domain, and both www and apex.
The fix, and the order it must happen in
Delete both defines. Do not replace them with hardcoded values: the correct values are already in the database, in the home and siteurl options, and that is where WordPress reads them from once the constants are gone.
Then, and only then, rebuild the indexables:
wp yoast index --reindexReindexing first makes it dramatically worse. Look four lines above those defines in a Bitnami config:
if ( defined( 'WP_CLI' ) ) {
$_SERVER['HTTP_HOST'] = '127.0.0.1';
}Combined with the request-derived WP_HOME, every WP-CLI run believes the site lives at http://127.0.0.1. Run the reindex before fixing wp-config and you convert a few dozen bad rows into every row.
The same trap applies to any bulk WP-CLI operation that writes Yoast metadata, including updating titles and meta descriptions in bulk.
Do you also need to redirect the stray hostnames?
Less urgently than you would think. Once WP_HOME is fixed, every hostname serves pages whose canonical points at the correct domain, which is exactly what canonical tags are for. The duplicate content resolves itself.
A redirect at the web server is still tidier. Just be careful if a CDN sits in front: if it forwards its own hostname rather than the visitor’s, a Host-based redirect will loop and take the site down. Confirm what your origin actually receives before writing that rule.
