Hosting, environments and HTTPS

Grade school

Your store lives on computers run by a company called Hostinger. Some YPB tools run on Microsoft’s Azure computers.

High school

YPB storefronts are WordPress and WooCommerce sites hosted on Hostinger. Some YPB platform services run on Microsoft Azure. YPB manages the hosting for you.

College

Storefront web hosting (WordPress, PHP, database, TLS certificates) is on Hostinger; selected YPB platform services run on Azure. Each site’s specific plan, server and account details are operational information and aren’t published.

Postgraduate

The split places customer-facing storefronts on managed WordPress hosting and shared platform services on a cloud provider. Each provider’s availability and data terms apply to its layer; YPB coordinates across them but doesn’t add a separate guarantee on top.

Developer

Storefront: WordPress/WooCommerce on Hostinger. Platform: Azure-hosted services. No per-tenant IPs, plans, accounts or SSH details are published; they’re provided privately where needed.

Grade school

Your store has three copies. One is for building, one is for trying things out, and one is the real store customers use.

High school

DEV

Where changes are built. It may be unfinished.

UAT

Where you check and approve changes before they go live.

PRD

Production: the live store your customers use.

All three are part of the standard setup. DEV and UAT are private: search engines shouldn’t list them, they don’t send email to real customers and they don’t take real payments.

College

Changes move DEV → UAT → PRD. Lower environments use approved subdomains, block indexing, contain outbound email to approved test recipients and use test payment modes. Data there is for testing, not a copy of live customer records to be reused.

Postgraduate

Environment separation controls risk: defects are found where they can’t reach customers, and approval happens on a representative build before release. Isolation must cover side-effects, not just URLs — mail, payments, webhooks and scheduled jobs — because a lower environment that can email real customers isn’t isolated.

Developer

Lower environments: X-Robots-Tag: noindex or equivalent, mail containment to an allowlist or sink, payment gateways in test mode, and no production credentials. Promotion is sequential; don’t hot-fix PRD outside the flow.

Grade school

Your store’s real address starts with https://www. The “s” means it’s safe. If someone types it another way, they’re sent to the right address automatically.

High school

Your live store’s official address is https://www.brand.example. Everything else — http://, or your domain without www — should send visitors straight there, keeping the rest of the address.

Plain http:// is only ever used to redirect. Nothing — logins, checkout, forms — should work over it.

College

YPB uses the www host as the canonical production address for consistency. Both the root domain and www need valid certificates, so the redirect itself happens over HTTPS. Redirect root → https://www in one step with a permanent redirect (301 or 308), keeping the path and query string, and avoid chains or loops.

Use the www address everywhere: canonical tags, sitemaps, internal links and marketing. Choosing www is a consistency decision; it doesn’t by itself improve search ranking.

Postgraduate

Consistent canonical signals (redirects, canonical tags, sitemap URLs, internal links) consolidate indexing on one host. Mixed signals split them. Certificates must cover both names so a visitor typing the root never sees a warning before the redirect. Keep DEV and UAT on their approved subdomains: they’re not production aliases.

Developer

Target: http://brand.example/p?q → 301 → https://www.brand.example/p?q (one hop); https://brand.example/* → 301/308 → https://www.brand.example/*; http://www… → HTTPS. <link rel="canonical" href="https://www.brand.example/…">. No mixed content. Don’t blanket-redirect API or webhook subdomains. Check with curl -sI. See Google canonicalization.

Grade school

The address book (DNS) only says where to go. Sending visitors to the right address is done by the website itself.

High school

DNS records don’t redirect anyone. They only point a name at a server. The redirect from your root domain to www happens on the web server after the visitor arrives, which is why both names need to point at your host and both need a certificate.

College

A “URL redirect” or “forwarding” option at a registrar is a web service the registrar runs, not a DNS record, and it often doesn’t support HTTPS properly. For YPB storefronts the redirect is configured on the hosting side, where the certificates live.

Postgraduate

Keeping redirects at the origin, beside certificate management, avoids third-party forwarding services that terminate TLS poorly or break paths. It also keeps redirect behavior versioned with the site rather than hidden in registrar settings.

Developer

dig shows only resolution; use curl -sI -L to trace redirects and confirm a single 301/308 with preserved path and query. Hostinger explains www resolution separately from redirects.