Domains and SSL
Webcore keeps public DNS, certificate state and site runtime configuration separate so each can be validated independently.
DNS preflight
Actions that depend on public hostname ownership, especially certificate issuance, require the public A record to resolve to the correct Webcore hosting node.
Local hosts-file entries, internal DNS overrides and stale recursive caches do not satisfy public ACME validation. When DNS has just changed, compare authoritative and public resolver results rather than trusting one cached response.
A DNS warning does not necessarily mean every site-management action must be blocked. Where an operation can be performed safely before cutover, the Panel can treat public DNS state as advisory and leave certificate issuance or final validation until the domain points at the managed node.
Let's Encrypt certificates
For normal production sites, Webcore manages certificate issuance and the associated Nginx HTTPS configuration.
If issuance or validation fails, the existing site and certificate state are left intact where possible rather than replacing a working configuration with a partial one.
Preview uses its own Webcore hostname and certificate, so a migrated site can be tested over trusted HTTPS before the production DNS record is changed.
HTTPS and WordPress URLs
Once production SSL is enabled, WordPress should use its canonical HTTPS URL consistently.
Mixed-content repair should only replace URLs that belong to the site's own canonical hostname. External HTTP links or application data are not safe to rewrite indiscriminately.
Before DNS cutover
Use Preview and Staging to test the managed installation before changing public DNS.
For migrations where the production IP itself will move to the new Webcore node, validate the imported sites while the node is on its temporary address, then complete certificate validation after the original production IP is reassigned and public traffic reaches the new node.
After cutover
After DNS or IP cutover, verify:
- the public A record reaches the intended Webcore node
- the production certificate is valid for the expected hostname
- HTTP redirects to the canonical HTTPS URL as intended
- WordPress home/site URLs are correct
- important frontend pages and WP Admin load successfully
- any CDN or reverse-proxy configuration is forwarding the correct client and origin information
Do not assume that successful DNS resolution alone proves the application and certificate transition is complete.