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.

WordPress Works by IP Address but Not by Domain Name

Reaching a server by IP proves network and a default web service respond. It does not prove DNS resolves correctly or that the web server maps the requested hostname to the WordPress virtual host. Testing WordPress directly by IP can also trigger redirects because WordPress stores its canonical domain.

Preserve current DNS and hosting configuration before changing both sides.

Define the failure

Record root and www results, HTTP/HTTPS, status, certificate and response body. Compare different networks/resolvers.

Capture:
A/AAAA/CNAME answers
nameservers and TTL
Host/SNI requested
virtual-host response
certificate hostname
WordPress home/siteurl

Do not treat a control-panel preview URL as the final domain test.

Verify authoritative DNS

Confirm registrar delegates to the intended nameservers, then inspect A/AAAA/CNAME records at that authoritative provider.

An old AAAA record can send IPv6-capable visitors elsewhere while A is correct. www may be a separate CNAME.

Avoid duplicate conflicting records. Lower TTL before planned changes; doing so afterward cannot clear already cached answers.

Check DNSSEC and negative caching

If DNSSEC is enabled, confirm the registrar DS record matches the active provider’s signing keys. A stale DS after nameserver migration can make validating resolvers return SERVFAIL while other tests appear normal.

Also account for cached NXDOMAIN responses. Their negative TTL comes from the zone SOA and can persist after creating a record. Do not disable DNSSEC casually; coordinate the key/delegation transition and verify it with authoritative and validating tools.

Review local resolution

Check the affected device’s hosts file, VPN, corporate DNS, router cache and browser secure-DNS setting. Internal split DNS may deliberately answer differently.

Flush only the relevant cache after recording its answer. Do not hard-code production IPs in staff hosts files permanently; future migrations will silently fail for those devices.

Test the hostname against the intended server

Use a hosts-file or an HTTP client that sets both destination IP and hostname/SNI. The hostname is required for name-based hosting and TLS.

curl --resolve example.com:443:203.0.113.10 https://example.com/

Use the real authorised values locally; do not publish origin addresses. This separates DNS from web-server configuration.

Check virtual-host mapping

cPanel/Plesk must attach the domain/alias to the correct document root. Nginx/Apache needs a server_name/ServerName and matching root.

A default hosting page means the request reached the server but no correct host mapping won. Check addon-domain/subscription settings rather than moving WordPress files immediately.

Avoid duplicate virtual hosts claiming the same hostname.

Validate SSL and SNI

HTTPS must serve a certificate covering root/www as used. A default certificate often means SNI/virtual host selection is wrong.

Install/renew Let’s Encrypt through the panel after DNS reaches the server and ACME validation paths work.

Do not bypass hostname verification or use an IP-address certificate as the permanent solution.

Align WordPress canonical URLs

Check home, siteurl and constants use the intended HTTPS domain/path. Access by IP may redirect correctly to the domain; that is expected WordPress behaviour.

Do not change stored URLs to the IP. That breaks cookies, links, email and SEO.

Behind Cloudflare/proxy, configure trusted HTTPS forwarding without accepting arbitrary headers.

Inspect proxy and firewall

If Cloudflare is proxied, confirm the origin accepts its requests and SSL mode matches a valid origin certificate. Compare proxied and DNS-only tests carefully.

Firewall rules should allow the CDN’s documented current networks while protecting direct access as designed.

Do not disable the firewall globally to make one hostname respond.

Verify services beyond the homepage

Test login, assets, REST, media, canonical redirects and both root/www. Confirm DNS answers worldwide after TTL and remove temporary hosts-file entries.

Recurring care should monitor DNS, certificate and virtual-host response by hostname. IP uptime is too shallow because real visitors always bring a domain and TLS name.