Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

`wp_options` Contains an Invalid URL After a Migration

WordPress uses the siteurl and home options to build administrator, asset and public links. If they still contain a staging domain, wrong path or HTTP scheme, login and front-end requests may redirect away from the migrated site.

Correct only proven values first. A whole-database raw replacement can corrupt serialised plugin and widget data.

Confirm the active database and prefix

Read DB_NAME and $table_prefix from wp-config.php without exposing credentials. In phpMyAdmin or MySQL, confirm the expected options table and recent content exist.

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Replace wp_ with the actual prefix. Run a read-only query before any update.

Understand the two URLs

siteurl identifies where WordPress core files live; home is the public site address. They are often identical but can differ when WordPress is installed in a subdirectory.

Do not force them equal without checking the directory layout and prior configuration.

Use the canonical HTTPS host, with no trailing slash in normal installations.

Check constant overrides

WP_HOME and WP_SITEURL in wp-config.php override database values in WordPress. A correct database may appear wrong because these constants still point to staging.

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Use these intentionally, not as duplicate contradictory configuration. Back up the file and remove temporary overrides after database repair if they are not part of the deployment design.

Correct precisely with a backup

Take a database backup and record old values. Use WordPress CLI where available:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Run in the correct document root as the appropriate user. Alternatively use two exact SQL updates through an authorised tool.

Do not include credentials in command history.

Handle multisite separately

WordPress multisite stores network and site domains across several tables and configuration constants. Changing only one options table can leave network redirects broken.

Inventory network domain/path, each site and cookie configuration. Use multisite-aware WP-CLI commands and a staging rehearsal.

Do not apply single-site instructions blindly to multisite.

Migrate URLs inside content safely

Once access returns, search for the old domain in posts, widgets, builders and plugin settings. Use a serialisation-aware WP-CLI search-replace with dry run:

wp search-replace 'https://old.example' 'https://example.com' --all-tables-with-prefix --dry-run

Review tables/counts before the real run and exclude GUID changes unless a specific migration policy requires them.

Align DNS, SSL and redirects

The corrected URL must resolve to the new server with a valid certificate. Standardise www/non-www and HTTP-to-HTTPS redirects without loops.

If Cloudflare or a reverse proxy terminates SSL, configure trusted HTTPS detection. Do not accept arbitrary forwarded headers from the public internet.

Keep the old domain controlled for safe legacy redirects where appropriate.

Inventory non-database URL sources

Old hosts can remain in environment variables, .htaccess, Nginx, Cloudflare redirects, theme files, JavaScript bundles, SMTP templates and external gateway dashboards. Search each source separately after the WordPress values are correct.

Do not replace an old hostname inside signatures, encoded licence data or third-party callback secrets. For every match, identify the owner and whether it is a public link, secure endpoint or historical identifier. This avoids turning a straightforward URL repair into a new integration outage.

Verify login, assets and writing

Test public pages, wp-login.php, administrator, editor save, media and password reset in a clean browser. Inspect Network for old-domain requests and mixed content.

Clear relevant page/object caches and confirm the values remain correct after cache warm-up. Recurring care should include a URL inventory in every migration; successful DNS is not enough when WordPress still believes it lives somewhere else.