Skip to content

Hostinger

Copy Premium Plugins Between Sites on Same Server

From legacy section: Hostinger / Server

Pattern: Needed Elementor Pro and WP Rocket on malkaribytali.com. Instead of downloading zips or asking Jim to upload, copied plugin directories from evolvebusiness.com on the same Hostinger server. Rule: When installing premium plugins (Elementor Pro, WP Rocket) on a new Hostinger site, check if they exist on another site first: ls /home/u488157871/domains/[other-site]/public_html/wp-content/plugins/ | grep [plugin]. If found, cp -r them over and activate with WP-CLI. Saves time and avoids license download hassles. Date: 2026-03-23

SSH Path Requires Full Path — No Tilde Expansion

From legacy section: Hostinger / Server

Pattern: wp --path=~/domains/... failed because SSH MCP doesn't expand ~. Rule: Always use full path /home/u488157871/domains/[site]/public_html in SSH commands. Never use ~ shorthand. Date: 2026-03-23

Wix Sites Don't Return Content via WebFetch

From legacy section: Hostinger / Server

Pattern: WebFetch on talikogan.com returned only Wix framework JS/CSS — no actual page content. Wix renders client-side. Rule: For Wix sites, use Chrome browser tools (navigate + get_page_text) to scrape content, not WebFetch. WebFetch only gets the initial HTML payload which on Wix is just framework code. Date: 2026-03-23

Wix JSON-LD is Server-Rendered — Use It for Bulk Scraping

From legacy section: Hostinger / Server

Pattern: Started with Chrome MCP to scrape Wix product pages one at a time. Discovered that Wix embeds JSON-LD structured data in the raw HTML source (server-side rendered). Python requests + BeautifulSoup can extract it without a browser. Rule: For Wix product scraping at scale, fetch raw HTML and parse <script type="application/ld+json">. Contains name, description, images, price, availability. Note: Wix uses non-standard capitalization — Offers (not offers) and Availability (not availability). Date: 2026-03-23

SSH MCP Timeout Doesn't Kill the Process

From legacy section: Hostinger / Server

Pattern: Ran WP-CLI import via SSH MCP. It timed out after 60s, but the server-side PHP process kept running. Started a second run via nohup — now two processes competed, creating duplicate-skip patterns. Rule: When an SSH MCP command times out, the server process may still be alive. Always ps aux | grep [command] before re-running. Kill orphans first. For long-running WP-CLI tasks, always use nohup from the start. Date: 2026-03-23

Hostinger LiteSpeed CDN Caches Aggressively — Install Plugin to Purge

From legacy section: Hostinger / Server

Pattern: Switched themes from TwentyTwentyFive to Hello Elementor. WP-CLI confirmed the switch, but the public site still served the old theme. x-litespeed-cache: hit with 7-day max-age. Clearing WP Rocket cache, object cache, and rewrite rules did nothing. Rule: Hostinger uses LiteSpeed CDN (hcdn server) with aggressive caching. To purge: (1) wp plugin activate litespeed-cache, (2) wp litespeed-purge all, (3) wp plugin deactivate litespeed-cache. Keep LiteSpeed Cache plugin installed but inactive for future purges. WP Rocket does NOT control the CDN layer. Date: 2026-03-24

Hostinger parked domain needs hPanel "Add Domain" — NS update alone leaves the zone empty

From legacy section: Hostinger / Server

Why: On 2026-05-18 Jim parked two keyword-rich domains (freeseochecks.com, freeseohealthcheck.com) to evolvebusiness.com. The first worked end-to-end (NS at registrar pointed to byte/pixel.dns-parking.com, Hostinger auto-populated @ ALIAS → <domain>.cdn.hstgr.net. + www CNAME + mail records). The second only had its NS updated at GoDaddy (cosmos/nova.dns-parking.com) — Hostinger's nameservers responded with a valid SOA (today's serial) but the zone was completely empty (HINFO RFC8482 answer, no A record). DoH lookups returned "lame delegation" / REFUSED. Hostinger DNS API said "Domain not found" because the domain wasn't registered in the account's domain module. The CDN endpoint (<domain>.cdn.hstgr.net.) DID resolve to real IPs server-side — Hostinger just hadn't wired the zone to it. Fix: Jim added the domain via hPanel's parking/add-domain flow on the evolvebusiness.com plan; records auto-populated within minutes; mu-plugin host-match caught traffic immediately with zero code changes. How to apply: When parking an external domain to a Hostinger hosting plan, two steps are required, not one: (1) point the registrar's NS to Hostinger's parking nameservers (Hostinger assigns different pairs — byte/pixel, cosmos/nova, etc. — both are valid), AND (2) explicitly add the domain via hPanel → Websites → [target plan] → Parked Domains / Add Domain. Step 2 is what registers the zone with Hostinger's DNS-management module and triggers auto-population of the @ ALIAS + www CNAME pointing to the existing site's CDN endpoint. Diagnostic shortcut: if mcp__hostinger-mcp__DNS_getDNSRecordsV1 returns [] (empty) for a domain whose NS is correctly pointed at Hostinger, the zone exists but step 2 was skipped. If it returns "Domain not found", same diagnosis. Don't try to manually write records via the API — it'll fail with "Domain not found" until hPanel registers the domain. Date: 2026-05-18

CommunityTech Plugin 404 ≠ Plugin Missing — May Mean Empty Kit

From legacy section: Hostinger / Server

Pattern: CommunityTech Elementor endpoints returned 404. Spent time troubleshooting plugin installation, but the actual issue was that the Elementor Kit had no settings configured yet. The 404 response body said "empty_kit_settings". Rule: When CommunityTech returns 404, check the response body. "empty_kit_settings" means the kit exists but has no data — use the update endpoints to populate it first. Only troubleshoot installation if the response says "endpoint not found." Date: 2026-03-24

Hostinger has multiple DNS pathways — only one is API-writable

From legacy section: SEO NEO / Workbook

Pattern: When attaching sandmans.net to Hostinger during the GoDaddy transfer, we cycled through three different Hostinger DNS pathways before finding one that worked: (1) "Connect External Domain" wizard — created a stub zone in Hostinger's dns-parking.com infrastructure, returned empty [] for GET but {"message":"Domain not found"} for write via API, blocked behind a NS-verification gate. (2) "Account-level Parked Domain" outside the website context — same problem. (3) Website-level "Parked Domain" attachment under sandmansblasting.com (hPanel → Hosting → sandmansblasting.com → Domains → Parked Domains) — this is the correct path for making Hostinger serve a parent's WordPress for an additional domain. Compounding the issue: Hostinger's Server IN-671 maintenance window (20:30-22:30 UTC) had verification queues stalled. We pivoted to Cloudflare DNS to bypass the entire Hostinger DNS stack. Rule: Hostinger has multiple "add a domain" pathways with different infrastructure backing them. For DNS-only management of an external domain (registered elsewhere): use the standalone DNS Zone Editor (Domains → DNS / Nameservers) — but be aware verification stalls are common and the API endpoint may be intermittently unavailable. For making Hostinger serve a website at an additional domain: use website-level Parked Domains (Hosting → [website] → Domains → Parked Domains) — this is the equivalent of cPanel "addon domain" and is what makes Apache/nginx route requests for that hostname to the parent site's document root. Don't use account-level parking for either case. Always check https://statuspage.hostinger.com/ for active maintenance windows before debugging API failures — server-cluster maintenance routinely blocks DNS provisioning. If Hostinger's stack is acting up and email is at risk, pivot to Cloudflare DNS (free, ~5 min to set up) rather than waiting on Hostinger's verification queue. Date: 2026-04-27

Hostinger primary-domain swap can leave edge CDN stuck — bypass via direct A-record to LiteSpeed origin

From legacy section: SEO NEO / Workbook

Pattern: During the sandmans.net primary domain swap on 2026-04-28, after Jim completed the Hostinger panel workflow (unpark sandmans.net → switch primary from sandmansblasting.com → re-park sandmansblasting.com), the Hostinger API immediately confirmed the website attachment as vhost_type: addon, is_enabled: true, with WP files moved to the new docroot and siteurl/home auto-updated by Hostinger's swap. Direct curl to LiteSpeed origin (156.67.77.152) returned WordPress with x-powered-by: PHP/8.3.30 perfectly. But every Hostinger CDN edge node tested (88.223.87.65, 88.223.87.78, 147.79.79.253) returned the static "Parked Domain name on Hostinger DNS system" template via server: hcdn for 30+ minutes. Cleared Hostinger's hPanel cache — no effect. Removed the DO_NOT_UPLOAD_HERE marker file from /home/u<user>/domains/<domain>/ — no effect. The edge config never reconciled with the addon attachment, despite the API and origin both showing healthy. We waited 30+ min before pivoting to a workaround. Rule: When swapping primary domains on Hostinger and the new primary stays stuck behind the parked-domain template at the edge for >15 min after the API confirms vhost_type: addon + is_enabled: true, don't wait for Hostinger support — change the DNS A record at your DNS host (Cloudflare, etc.) to point directly to the LiteSpeed origin IP. Find the origin IP by curl-resolving against known Hostinger origin IPs (156.67.77.152 currently works for the u488157871 plan; verify by curl -sI --resolve domain:443:156.67.77.152 https://domain/ and looking for server: LiteSpeed + x-powered-by: PHP). The site comes up immediately. Tradeoff: lose Hostinger's edge CDN benefits (caching, edge SSL termination, DDoS shielding) but gain instant reliability — heavily favorable for SEO/canonical sites where reliability beats micro-latency. If Hostinger's edge propagation eventually recovers (check periodically), the A record can be reverted to an edge IP for CDN benefits — low priority cleanup. Date: 2026-04-28

Hostinger upload bandwidth: chunk large uploads, parallel SCPs share total bandwidth (~5 MB/s aggregate)

From legacy section: SEO NEO / Workbook

Pattern: Empire Media Network deployment required uploading 1.7 GB of compressed PDFs in one tarball. Single-stream SCP at 4 MB/s = ~7 minutes baseline, but Bash tool's default 2-min timeout killed it at 1.4 GB (truncated tarball, no error returned). Switching to 5 parallel chunked tarballs (sl/crl/sb/spac/covers) gave failure isolation but didn't speed up total throughput — Hostinger SSH appears bandwidth-throttled at ~5 MB/s aggregate per account, divided across all concurrent connections. Single stream gets ~3-5 MB/s; 5 parallel streams each get ~1 MB/s. Rule: For multi-GB Hostinger uploads: (1) ALWAYS use run_in_background: true with timeout: 1800000+ on the Bash tool — never let a long SCP run in foreground default-timeout. (2) Chunk by logical group (per-prefix here: sl/crl/sb/spac) BUT understand it doesn't increase total speed — only increases failure isolation (one chunk failing doesn't lose all 4.6 GB of progress). (3) Smaller chunks (50-200 MB) finish faster individually, freeing pipeline downstream — extract them as soon as they land. (4) For very large single chunks (1 GB+), run a background Monitor polling stat -c%s remote-file every 60-120 sec — gives visible progress + auto-detects completion when size matches local. (5) Plan for ~10 min/GB upload time when scoping deploys; a 4.6 GB total upload took ~75 min wall-clock parallel. Date: 2026-04-28

Hostinger Site Mailer verification = SendGrid CNAMEs (no separate Site Mailer DKIM exists)

Moved to sops/sendgrid-domain-auth.md on 2026-05-20 — see SOP for the full domain auth playbook. Key gotcha: don't hunt for "Site Mailer-specific" records — they're standard SendGrid CNAMEs (em#### + 2× dkim).