WordPress canonical points to the old domain: fix its source after migration

Confirm that an old canonical is still being sent

After a migration, your pages open on the new domain, but a canonical tag still names the old one. First check whether this address is actually being sent today or appears only in an old Google record. The desired result is an indication consistent with the chosen public page, without redirecting every page to the homepage.

A canonical suggests to search engines a representative URL for identical or very similar content. It does not redirect the visitor and does not guarantee that Google will adopt that preference. An error can therefore remain invisible during normal browsing while sending a conflicting indexing signal.

Start with an affected page, its final URL, and the expected target. Keep the received value and the time. If the new site is intended to replace the old one, the correction generally concerns sources still inherited from the latter. However, a deliberate canonical to another publication or version requires editorial approval: do not automatically replace it solely because it points to another domain.

Choose a target for each page before changing settings

Prepare a short mapping of old URLs, final new URLs, and expected content. Include the homepage, an inner page, and a post if the site has any. This comparison distinguishes a general domain problem from a manual override limited to one content item. A single example does not necessarily describe every archive or language.

Open each chosen target and check that it displays the correct public content using the intended protocol and domain variant. A canonical must not name an unrelated page to artificially recover its signals. If several old pages have been consolidated, have that mapping approved instead of merely replacing the domain name while retaining a path that is now wrong.

Keep the initial values and prepare an appropriate backup before correcting any site addresses or files. Arrange access to files or hosting that remains usable if the administration interface logs you out. On a copy, neutralize the usual external effects. The expected evidence is a corrected public response, not just a saved settings field.

Read the canonical in the public HTML document

Open the final page while logged out of WordPress, view its source, and search for canonical. Check that it is a link element whose rel attribute contains canonical, then record its href target in the document’s head. A search limited to double quotes could miss single-quoted markup. Do not confuse a mention of this code in an article’s text with an actual page annotation.

Look for multiple annotations, especially a correct address alongside an old one. Adding a second canonical does not correct the first and can make the preference ambiguous. Keep all values found so you can identify their owners. An element visible only after a local change in browser tools is not a correction to the site.

Then compare an inner page and the homepage. If every page points to the same old homepage, look for a hard-coded value or global configuration. If only one page is affected, examine its specific SEO field first. WordPress core produces its native canonical for singular content views; archives and other contexts may be managed by a different component. Do not extrapolate their source without checking.

If the initial source and rendered page differ, a script may be modifying the annotation. Compare both versions at the same URL and have the responsible component corrected. Google recommends providing the canonical in HTML and not subsequently replacing it through JavaScript. A local browser edit does not change what the server publishes.

Also check for a Link header

The canonical may be specified in an HTTP Link header, including for documents that are not HTML. In Chrome, open developer tools, then Network before reloading the page. Select the final document, open Headers, then Response Headers. Look for a Link value containing rel="canonical" and compare it with any HTML element.

With an authorized terminal, the command below reads these headers through a bounded GET. Replace the fictional domain and path; on Windows, use curl.exe and NUL instead of /dev/null. No credentials are added, and redirects are not followed automatically. If an intermediate response is received, identify its destination before another read.

Do not remove every Link header: some have other purposes. If an old canonical exists only at this layer, have someone find the precise server, proxy, or intermediary-service rule. Correcting an SEO field will not necessarily change a header added afterward. Keep the record private, because other headers may contain information that does not need to be published.

The command finishing is not proof of a 200 status: curl can receive a 403 without reporting a transfer error. Read the status line and distinguish an intermediate response from the final content’s response. The -q option must remain first to ignore an unexpected personal configuration.

curl -q --silent --show-error --connect-timeout 5 --max-time 15 --dump-header - --output /dev/null 'https://nouveau.invalid/page-publique/'

Attribute the output to the correct component

For each page, collect the canonical received, the context, and the active SEO manager. A plugin’s HTML comment may provide a clue, but does not prove that it produces every annotation found. A theme, must-use plugin, or hosting rule may add a second source.

For a published individual content item, WordPress core calculates a canonical from the permalink and can filter it. An SEO manager may replace this output or apply a manual value. An incorrect base address can therefore propagate into automatic values, while an old field remains wrong even after the general settings are corrected.

Proceed by scope: native addresses if several automatic links retain the old domain; the page field if the error is isolated; code or a header if a second value persists. On a copy, a targeted component comparison can help attribute the output. Preserve dependencies and restore its state after the test. Do not leave the site without metadata management merely to hide the wrong line.

Correct native addresses only if they are wrong

On a self-hosted installation, this approach requires settings permissions and the prepared rollback method. In Settings, General, compare WordPress Address (URL), which corresponds to the core location, with Site Address (URL), which corresponds to public access. They may legitimately differ when an installation is in a subdirectory.

If an old value is confirmed incorrect, record both initial values and correct only the affected field, then click Save Changes. Do not remove a useful subdirectory to make the fields identical. Confirm beforehand that the new domain and its HTTPS really serve the intended installation; changing a field does not carry out an entire migration on its own.

Log back in at the definitive address and check the control pages and their canonicals. If a field is grayed out, it may be enforced in configuration: go to the responsible file rather than forcing the form. If a regression occurs, restore only the changed value through the planned rollback method. Do not restore an entire old database over an active site that has since received new data.

On WordPress.com, instead check the primary address managed by the service. For an already connected, eligible domain and a paid plan, open the Hosting Dashboard, select the site, then Domains. In the confirmed domain’s row, use the three dots in the Actions column, then Make primary site address. Visit the site in a new tab and reread its canonicals. If the domain is not ready or the test fails, restore the previous primary address through the same menu; do not apply the configuration block below to this environment.

Correct existing constants in wp-config.php

This advanced approach concerns a self-hosted single-site installation where WP_HOME or WP_SITEURL actually enforces the old domain. It requires authorized access to the correct installation’s wp-config.php file and a private copy of its initial state. These constants override the values used by WordPress without changing those stored in the database. Removing them later may therefore reactivate the old saved addresses: also plan to bring the configuration back into agreement before removing them.

Find their existing definitions and adapt only their addresses after validating the arrangement. The fictional example shows a homepage at the root and core in /wordpress. This subdirectory is inappropriate for core at the root. Do not paste these lines in addition to other definitions, and do not add them to hide a configuration whose source you do not know.

The lines below replace existing definitions in their intended location; they are not a standalone file. Do not add a second PHP opening tag. Save the file while preserving its PHP structure, then log back in and check the homepage, an inner page, and the canonical. If access or paths become incorrect, immediately restore the initial file through backup access. Configuration injected by the host or a multisite network requires its owner’s procedure; this block must not automatically be transferred there. Do not share the rest of the file, which notably contains database credentials.

define( 'WP_HOME', 'https://nouveau.invalid' );
define( 'WP_SITEURL', 'https://nouveau.invalid/wordpress' );

Remove an old manual override in Yoast SEO

If Yoast SEO already manages the content, check its Canonical URL field. As of November 3, 2026, the directory version is 28.8, by Yoast, requiring at least WordPress 7.0 and PHP 7.4, with testing declared up to WordPress 7.1.4. The canonical setting is available free; no Premium purchase is required for this check.

The current code gives precedence to a manual canonical value. When no value overrides the calculation, it uses the content’s generated address. Clearing an old override therefore makes sense if the page should now follow that calculation and the general addresses are correct. If a different canonical is still intended, enter its complete approved target, not merely the homepage.

1. Open the affected content in the editor and keep the field’s initial value.
2. In the Yoast SEO panel, open Advanced, then Canonical URL.
3. Remove the old override to return to the expected calculation, or replace it with the exact absolute URL approved for this content.
4. Save the update and reread the canonical in the public response.
5. To undo this test, restore only this field’s initial value and save again.

Distinguish an old setting from precomputed SEO data

After a migration, the SEO manager may hold precomputed content data. Start by correcting the actual address sources and manual fields; a calculation operation will not turn a wrong value that is still saved into a sound editorial decision.

In Yoast SEO, Tools, the Optimize SEO data area may offer Start SEO data optimization. If this operation is relevant and available for your installation, prepare it on a copy with its backup, run it once, and wait for its result. Record any error instead of starting multiple simultaneous runs. This process can require resources on a large site; it does not by itself guarantee a corrected canonical.

Then check the same pages and their current values. If the button is unavailable or the data remains inconsistent despite correct sources, provide examples to the maintainer. Do not delete plugin tables or install a bulk reset tool to continue this simple check. This is not an instantly reversible operation; the copy must remain restorable so the test can be abandoned without touching new production data.

Correct the owning code or header without adding a second canonical

If an old address remains coded in a theme or plugin, have its exact output located on a copy. For core, the value may pass through get_canonical_url; Yoast notably provides the wpseo_canonical filter. Understand the targeted context before removing a condition, especially if it handles languages, consolidated pages, or pagination.

Keep the initial file and correct the responsible source, not WordPress core or a generated file that will be overwritten. Do not add a correct tag to the template to cover another incorrect one. If two components each produce a canonical, assign responsibility to the one intended for this installation and verify the output after the intervention.

For a Link header added by the server or an intermediary, keep the previous rule and have only this canonical annotation changed. Other Link values may remain necessary. The expected result is one consistent preference for the control page, without losing other functions. If a regression occurs, restore only the affected file or setting, then resume attribution using the two saved responses.

Align the canonical with other migration signals

A correct tag can still conflict with redirects, internal links, or a sitemap that favors the old domain. Check an old page’s route to its counterpart and the links used on the new site. If the new domain redirects to the old one when the migration was intended to do the reverse, correct that rule at its source.

The chosen target must correspond to the content and remain accessible at its final address. Avoid chains that declare one canonical and then redirect to another variant. Do not canonicalize every page to the homepage to make old URLs disappear: that does not make their content equivalent.

Check the managed sitemap’s URLs and links on the main pages. A configuration correction may update them, but manually entered links may still need targeted treatment. Take an inventory before a bulk migration operation and use a tool suited to WordPress data. A blind SQL replacement can damage serialized values. Correcting the canonical is one aspect of consistency, not authorization to rewrite the entire database.

Do not block a variant in robots.txt to impose a canonical: Google must be able to read the signal. A noindex serves another purpose and is not the method to use for choosing between two equivalent versions. A consistent sitemap helps signal your preference without imposing it.

Check cache layers after the correction

An old HTML copy may continue to contain the wrong tag even after a correct save. A proxy may also retain an old header. Identify the layer serving the response before repeating the same edits in the editor several times.

After correcting the source, invalidate only the affected responses using the cache system already in place, then read the page again while logged out. Also check a second read after the copy has been rebuilt. If the correct canonical appears only for an administrator, compare the genuinely public response; success in your session is not enough.

If the old value returns after deployment, examine what is being copied from staging: a general setting, an individual field, a custom file, or intermediary-service configuration. Record the step that reintroduces it. Constant purging does not resolve this deployment defect. Clearly distinguish production from the copy, and do not synchronize the entire active database to transfer a correction to one field.

Compare the current response with Google’s known choice

In the Search Console property covering the new URL, inspect the final page. In the known index data, compare the user-declared canonical and the Google-selected canonical when displayed. Record the crawl date: the known choice may still reflect the version before your correction.

Use Test live URL to check certain aspects of the current page and view the received HTML when the tool allows it. The live test does not predict which URL Google will eventually select as canonical. A consistent response today and a different old selection therefore do not necessarily call for changing all the settings again.

After a useful correction, an indexing request limited to important pages may help signal the change using authorized permissions. It guarantees neither a reassessment date nor adoption of your preference. If Google retains another URL after new crawls, examine the actual equivalence of the content and remaining conflicting signals. Do not add more manual fields pointing to the same target simply to try to force this choice.

Validate the result and prevent reintroduction

Revisit the homepage and control pages while logged out. For each, check the final address, content, HTML canonical, and any HTTP annotation. They must match the approved decision, with legitimate exceptions documented. Also check another language or a paginated page if the installation uses them: a global domain correction must not erase their logic.

Keep a record of the field, constant, or rule changed, with initial values and the current result. If a test is abandoned, reverse only that change and check access again. Calculations or copy restorations must not overwrite data produced meanwhile on the active site.

Add canonical checks to the migration procedure and future deployments. For further help, provide the old and new control URLs, the annotations actually received, their dates, the responsible components, and the Search Console comparison. Do not attach the complete wp-config.php or account credentials. This record allows a precise source to be corrected and its uptake tracked without promising rankings.

Check a migration sample without a global canonical

Build three real mappings: a post whose path remains identical, a renamed page, and a page merged with another. For each, first write down the expected editorial destination. Mechanically replacing the domain sometimes suffices in the first case; it may produce an incorrect target in the other two.

Then compare four items on each row: the old address’s redirect, the new page’s canonical, the internal link leading to it, and the URL published in the sitemap. Their consistency is a better criterion for correction than a filled-in SEO field. The merged page must actually find its equivalent in the new content; a canonical does not turn two different pages into duplicates.

With Yoast already active, remove the manual value only if the automatic calculation matches this decision. Otherwise, document the special target and check the public HTML after saving. For developers, look for a condition or constant responsible for incorrect output; do not replace the canonical filter with a function that always returns the same URL. Such a global filter can affect content whose equivalence you have not assessed.

Keep these three controls for the next deployment. If one mapping becomes incorrect, restore only its setting or owning code. The local check does not prove a new Google selection: record the known crawl date in Search Console separately.