Hostinger CDN Settings for a Text-Based Knowledgebase Website

Quick Answer

For a public knowledgebase serving readers in India, the USA, and other countries, a reasonable Hostinger CDN starting configuration is CDN enabled, Medium security, no country restrictions, and the TLS 1.3-only restriction switched off. WebP compression and Smart image optimisation can remain enabled. These are starting recommendations for a public information website, not mandatory settings for every application.

For a website where more than 90% of articles contain no images, concentrate on public article caching, correct content delivery, and access for legitimate readers. Image settings have limited influence on those text-only pages. Check country filtering first: an active “Allow only specific countries” configuration with an empty allowed list can prevent all readers from accessing the website.

Scope and Preparation

This guide covers the Analytics, Website optimisation, Traffic blocking, and Security controls in Hostinger CDN. Examples use knowledgebase.example.com. Available controls can vary by hosting plan.

A Content Delivery Network (CDN) handles requests through distributed servers. Its cache stores reusable responses so some requests can be answered without returning to the original hosting server, called the origin.

Before changing settings:

• Confirm that you have selected the correct website or subdomain.
• Record the existing CDN settings and any intentional IP or country restrictions.
• Keep a copy of the website’s DNS records, particularly before enabling or disabling CDN.
• Identify public articles, staff-only pages, search functions, and form submissions.
• Keep an application backup before changing server-side caching code or configuration.

You need an account with permission to manage the website. These browser-based steps do not require administrator or root privileges on your computer.

For web and cloud hosting, open Websites → Dashboard → Performance → CDN → Manage. Some hosting plans expose a different menu or fewer controls.

Recommended Starting Settings

The image values above are starting recommendations, not requirements. A site with few images has little reason to spend extensive time adjusting them unless a visible problem appears.

Traffic Blocking: Preserve Worldwide Access

Understand the Two Country Modes

Block specific countries denies access from the countries listed. An empty list introduces no country-based exclusions. Allow only specific countries permits the listed countries and blocks others.

For an international public knowledgebase, choose the first mode and leave its country list empty unless there is a specific operational reason to restrict access. Having most readers in India and the USA does not justify blocking everyone elsewhere.

1. Open Traffic blocking.
2. Select Block specific countries.
3. For unrestricted international readership, ensure the blocked-country list is empty.
4. Complete any confirmation or save prompt.
5. Reopen the settings and verify the saved state.

Use IP Blocking Selectively

An empty manual IP-block list does not mean all CDN security filtering is disabled. It means no addresses have been manually excluded through that list.

Before adding an address or network range, identify the unwanted requests and check whether the address also serves legitimate visitors, an office, a monitoring service, or an integration. Preserve the previous list so an incorrect block can be removed.

Website Optimisation: What the Image Controls Do

WebP Image Compression

This control converts eligible images into WebP for delivery. It can reduce image transfer size, but it does not compress the wording of an article or make database queries faster. Leaving it enabled is a reasonable starting choice.

Smart Image Optimisation

This control adjusts image dimensions and compression for desktop and mobile delivery. The maximum width limits the delivered image width; it does not set the width of the article layout.

The quality percentage is a compression setting. It is not a promised percentage reduction in file size or loading time.

For the few articles containing diagrams or screenshots, verify that small text remains readable. Increase the width if resizing removed necessary detail, or increase quality if compression caused visible damage. If needed, compare with Smart image optimisation disabled. Change one setting at a time and retain the previous values.

For predominantly text-only articles, leave sensible image defaults in place and focus performance testing on the page itself.

Security: Choose Protection That Preserves Legitimate Access

Security Level

Medium is Hostinger’s default and a suitable initial choice for a public knowledgebase. The level controls how aggressively visitors are challenged based on assessed threat.

Do not select the highest setting simply because it sounds more secure. More aggressive challenges can interfere with legitimate readers or automated requests. Reserve I’m Under Attack! for an active attack rather than normal operation.

Test staff login, search, subscriptions, and other important actions. If a legitimate request fails, record the failing action and inspect the relevant security and blocking rules before changing the level.

A justified adjustment should preserve as much protection as practical. Avoid setting security effectively off to solve a single unexplained failure.

TLS 1.3-Only Restriction

Transport Layer Security (TLS) protects HTTPS connections. Leave Use only the latest TLS version (TLS 1.3) switched off for a broadly accessible knowledgebase unless you have verified that all required clients support TLS 1.3.

In Hostinger’s documented configuration, leaving this restriction off permits TLS 1.2 and TLS 1.3. It does not switch off HTTPS or prevent compatible browsers from using TLS 1.3.

The Traffic over TLS chart is a report of connection protocols, not a cache setting. If you later consider enforcing TLS 1.3 only, first review client usage and test required integrations. Restore the previous setting if the restriction prevents legitimate clients from connecting.

Analytics: Reporting Period Is Not Cache Lifetime

The Select period menu controls how much historical activity the dashboard displays. Choose a short period when checking a recent change and a longer period when reviewing trends.

Choosing seven days does not cache articles for seven days. Similarly, a 30-day option, where available, is a reporting choice rather than a retention instruction for website content.

Use analytics to identify changes in request volume, cache behavior, and response errors. CDN requests are not equivalent to unique readers or article views: one page can request multiple files, and automated clients can also generate requests.

If the panel shows No data yet, first verify that the site is accessible and requests are actually reaching the CDN. Do not repeatedly enable and disable CDN merely to populate a graph.

Article Caching Matters More for a Text-Based Website

CDN Enabled Does Not Mean Every Article Is Cached

Hostinger documents automatic caching for static files and conditional caching for HTML on ordinary web hosting. A PHP article can pass through the CDN while its HTML is still fetched from the origin for every request.

Therefore, turning on CDN and image optimisation does not establish that article pages are cached. Inspect their responses before deciding whether further configuration is needed.

Hostinger’s caching documentation describes HTML caching through supported application or plugin headers. Recognised WordPress and shopping-cart cookies receive special handling; do not assume those recognitions cover a custom application’s session cookies.

Checks Before Enabling Shared Article Caching

The following are application-review requirements, not instructions to switch on a blanket “cache everything” rule:

• Separate article identifiers: For URLs such as view_article.php?id=101 and view_article.php?id=102, confirm that the caching configuration keeps the articles separate.
• Staff sessions: Exclude authenticated pages, editing controls, and previews from shared caching.
• Public response consistency: Check whether otherwise public pages include user-specific messages, security tokens, or personalised elements.
• Publication updates: Establish how publishing, correcting, or withdrawing an article invalidates cached copies.
• Search and forms: Initially keep these dynamic unless their behavior has been specifically reviewed.
• View counting: Verify how readership statistics are collected before caching the complete HTML response.

Why Article View Counters Need Attention

If a counter increments only when the article’s PHP code executes, a response served entirely from CDN cache may bypass that increment. Whether this affects your site depends on its implementation.

A lower application counter after caching is enabled does not automatically prove that readership declined. Compare its collection method with your analytics and CDN request records. Also distinguish an outdated displayed count from a failure to record new views.

How to Confirm CDN and Cache Behavior

1. Confirm that CDN is enabled for the intended hostname in the hosting dashboard.
2. Open a public article in your browser.
3. Open developer tools and select Network.
4. Reload the page and select its main document request.
5. Inspect Response Headers for x-hcdn-request-id, which Hostinger documents as identifying delivery through its CDN.
6. Check x-hcdn-cache-status for the article and a public static file.
7. Repeat a normal network request to observe whether eligible content produces a cache hit.

A browser entry served from memory or disk cache does not demonstrate a new CDN request. Also, an article marked DYNAMIC does not mean the CDN is disabled.

Compare several measurements from representative reader locations, such as India and the USA. Use the same pages and similar conditions, and separate first requests from repeated requests. Do not promise a speed improvement based only on the enabled switch.

Publishing Changes and Clearing Old Content

When an update remains stale, open Websites → Dashboard → Performance → CDN and use Flush cache. Hostinger documents this as invalidating the website’s CDN cache; it does not clear browser, server, or application caches.

For repeated editing, Development mode can temporarily bypass CDN caching. Turn it off when finished. It is not equivalent to disabling CDN routing or all security checks.

If old content remains, verify that the origin contains the update and inspect other caching layers. Clear only the relevant caches. Avoid repeated flushing during performance measurements because it removes the cached responses you are trying to evaluate.

After correcting a public article, test the result as a logged-out reader. A correct preview inside the administration area is not sufficient verification.

Troubleshooting and Recovery

Visitors Cannot Access the Website

Check country and IP rules first. In particular, inspect any empty allow-only country list. Test through a second network to distinguish a general access problem from a local one.

If the failure began immediately after activation and the browser reaches an unexpected site, review DNS routing against the saved records rather than changing image settings.

Login, Search, or Form Submission Fails

Identify the failing request in the browser’s Network panel. Record its URL, HTTP method, response status, time, and request identifier. A 403 response alone does not establish whether the CDN or application caused the refusal.

Review blocking rules and use a controlled security-level adjustment only when evidence points to CDN filtering. Hostinger documents that precise endpoint or external-service exceptions require support rather than a dashboard allowlisting control.

Do not send passwords, session cookies, authentication tokens, or private form contents with diagnostic information.

The Website Is Not Noticeably Faster

Check whether article HTML remains dynamic and whether Development mode is active. For a site with very few images, changing image quality is unlikely to resolve slow page generation.

Have the application maintainer investigate slow server processing when necessary. CDN caching cannot make uncached database queries execute faster.

Revert a Setting or Disable CDN

For an isolated problem, restore the specific setting you changed first. This avoids introducing an unnecessary routing change.

If full deactivation is necessary, record the current DNS configuration and use the website’s Disable control. Hostinger documents that disabling restores routing to its hosting plan; an earlier intentional custom destination may need to be restored separately.

DNS changes can take up to 24 hours to propagate according to the provider. Verify the correct destination, HTTPS, public articles, and staff access after rollback. Do not repeatedly toggle CDN while different networks are still using cached DNS answers.

Final Configuration Checklist

• The intended website’s CDN is enabled.
• International readers are not excluded by an accidental country rule.
• Medium security permits the website’s legitimate functions.
• The TLS 1.3-only restriction remains off unless compatibility has been verified.
• Image defaults are retained unless visual testing identifies a reason to change them.
• Development mode is off during normal operation.
• Public article caching has been checked separately from static-file caching.
• Staff sessions, article identifiers, view counters, and publishing updates behave correctly.

Sources

• Hostinger CDN: How to optimize your website
• Hostinger CDN: How to block countries
• Hostinger CDN: Security levels
• How Hostinger CDN caching works
• Hostinger CDN: How to confirm it is active and what it speeds up
• Hostinger CDN: How to clear the cache
• Hostinger CDN: How to fix blocked legitimate requests
• Hostinger CDN and your DNS records