Hosting, environments and HTTPS

Grade school

Your store lives on computers run by a company called Hostinger. YPB looks after it for you. Some YPB tools run on Microsoft’s computers, called Azure.

High school

YPB hosts storefronts on Hostinger and runs some platform services on Microsoft Azure. Hosting is currently included in your membership. YPB doesn’t promise a separate uptime percentage; availability depends on those providers.

College

Storefront hosting (WordPress and WooCommerce) is on Hostinger; certain YPB platform services run on Microsoft Azure. Each provider publishes its own service terms. YPB doesn’t offer an independent uptime SLA or pass through provider credits; YPB’s commitment is how it responds to your support requests.

Postgraduate

Availability is inherited from upstream providers under their own agreements, so YPB states no independent SLA rather than repackaging vendor terms as its own guarantee. The support commitment — 24-hour acknowledgement with an estimate — is a separate, service-level promise about response, not uptime.

Developer

Storefronts: WordPress/WooCommerce on Hostinger. Platform services: Microsoft Azure. Internal topology, accounts and addresses are not published. Vendor terms: Hostinger technology, Microsoft online services SLAs (vendor-specific, not a YPB guarantee).

Grade school

Your store has three copies. Two are practice copies where YPB tries things safely. The third is the real store that shoppers use.

High school

Every YPB store has DEV (where changes are built), UAT (where you review them) and production (your live store). DEV and UAT are private, aren’t shown in search results, and don’t email real customers or take real payments.

College

Three environments separate risk: DEV absorbs experiments, UAT is the acceptance stage that mirrors production, and production serves customers. Lower environments are access-restricted and non-indexed, and their mail and payments are kept away from real customers so tests can’t cause real-world effects.

Postgraduate

The progression DEV → UAT → production is a control: each change is exercised and accepted before it touches real customers, money or email. Isolation of lower environments is part of that control, not an option, and applies equally to email, payments and indexing.

Developer

Lower environments keep their own approved hostnames (for example dev.example.com, uat.example.com), never www.dev. They send X-Robots-Tag: noindex or equivalent, restrict access, route all mail to approved test recipients and use payment test modes. Production is the only environment on the canonical www host.

Grade school

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

High school

Your live store’s address is https://www.example.com. Under YPB’s standard, plain http:// is used only to send visitors to the secure address, never for forms or logins. Both example.com and www.example.com need valid certificates.

College

YPB uses www as the canonical host for consistency, and every canonical tag, sitemap and internal link uses it. That’s a consistency choice, not a search-ranking advantage. Certificates must cover the apex and www before any redirect is switched on, so no visitor lands on a certificate error.

Postgraduate

A single canonical origin concentrates cookies, analytics and search signals on one host and avoids duplicate-content ambiguity. HTTP remains only as a redirect so that credentials and customer data never traverse an unencrypted channel. Mixed content is excluded on every page.

Developer

Canonical origin https://www.example.com; <link rel="canonical">, sitemap URLs and internal links use it. TLS certificates cover both example.com and www.example.com. See Google’s canonicalization guidance; it doesn’t favour www over apex.

Grade school

The address book (DNS) only finds the store. A different part, the web server, sends visitors to the right address.

High school

DNS records don’t redirect anyone. They only point names at servers. The web server does the redirect: http://example.com/shop?x=1 goes straight to https://www.example.com/shop?x=1, keeping the page and anything after the ?.

College

Every variant (http apex, http www, https apex) redirects in one hop to the https www URL with the same path and query, using a permanent redirect (301 or 308). Chains and loops slow visitors and confuse crawlers. Other service subdomains, such as APIs or webhooks, aren’t redirected blindly.

Postgraduate

Redirect policy is an origin-level contract: single hop, path and query preserved, permanent status, no loops. Scoping it to the storefront hosts avoids breaking machine clients on other subdomains that don’t follow redirects safely.

Developer

Expected behaviour:

$ curl -sI http://example.com/shop?x=1
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/shop?x=1

$ curl -sI https://example.com/shop?x=1
HTTP/2 301
location: https://www.example.com/shop?x=1

308 is used where the request method must be preserved. Add HSTS only once every subdomain serves HTTPS.

Grade school

YPB tells you the exact settings for your own store in private.

High school

The exact DNS values for your store’s environments are specific to you. YPB shares them privately; they will also appear in the signed-in support portal when it is available.

College

Site-specific records are private configuration. Public pages only show the pattern (see web records). Change only the records YPB gives you, and keep your mail records as they are.

Postgraduate

Keeping per-tenant configuration behind authenticated access prevents one customer’s addresses from being mistaken for another’s and avoids publishing infrastructure details.

Developer

The portal will show records only after your identity and organization membership are verified server-side; an unmapped site shows an unresolved state, never another tenant’s values.