Hostinger setup

Start with an important public page and compare its returned HTML with the completed browser page. A website that already returns meaningful content may not need a rendering connection. Use the setup guide to choose the smallest change supported by the evidence.

This guide covers a rendering connection. PB's AI Visibility, full article generation and reviewed CMS publishing have their own workflows; follow How PB Works to see the wider platform.

Buying a domain, hosting or email from Hostinger does not establish where its active DNS zone is managed. Check the domain's current nameservers before editing records.

Hostinger can display a saved DNS zone even while another provider's nameservers are active. Editing that saved zone does not change the active public records.

For Hostinger-managed DNS, its current DNS zone editor guide describes the relevant panel. Hosting accounts use the website's Advanced → DNS Zone Editor area; domain-only accounts can use the DNS area. Confirm that you are editing the intended domain and zone.

For managed routing, PB needs a stable, public HTTPS address that continues serving the intended website after the public hostname is connected. A temporary or preview URL is not automatically a suitable production origin.

Test the proposed origin without signing in. Check important routes, assets and redirects. It must not require a login or browser-only challenge, and must not redirect back into the public hostname being connected.

If your hosting setup supports a separate origin subdomain, configure and verify it before changing public routing. If no suitable origin exists, use a supported server-side integration where available or resolve the hosting requirement first. Read Find your origin URL.

Choose the website in PB and open its authenticated setup instructions. Copy the exact DNS and certificate-validation records into the authoritative zone. Match the provider's host/name field format; do not append the domain twice.

Keep the site's existing canonical hostname. A generic www example is not an instruction to change a root-domain canonical. Use the site's supported apex instructions when connecting a root domain.

Keep a copy of existing records and correct only confirmed conflicts for the connected hostname. Preserve nameservers, MX, SPF, DKIM, DMARC and unrelated TXT records. Check that email still works after the website-routing change.

Redirect the alternate hostname to the chosen canonical while preserving the path and query string. Test a deep URL, not just the homepage. Keep canonical tags and sitemap URLs consistent with that choice; see root and www configuration.

DNS and certificate validation timing varies. Refresh status after checking the current records. A Pending label alone does not establish a DNS error or justify resetting setup.

Run Verify Installation on the intended public URL. Review the final hostname, response status, readable content and available delivery evidence. Compare visitor and crawler-style responses; those profiles do not prove crawler identity or indexing.

If the response and setup label disagree, use troubleshooting before another DNS edit. Missing individual cache headers do not establish the entire routing cause.

Monitor important published pages with Health and Monitoring. Rendering improves delivery where it is needed; it does not guarantee indexing, rankings or AI citations.