Skip to main content

Advanced SiteGround SuperCacher: Excluding Custom Dynamic Pages via .htaccess

 There are few debugging scenarios more frustrating than a React application state desynchronizing because the hosting environment aggressively cached a JSON response or an HTML partial.

For developers hosting Headless WordPress or hybrid React applications on SiteGround, the NGINX Direct Delivery and Dynamic Cache layers are generally beneficial. However, when building shopping carts, user-specific dashboards, or secure API endpoints, these caching layers often ignore standard plugin-based exclusions. Relying on the SG Optimizer plugin’s GUI is frequently insufficient for complex URL structures involving wildcards or specific regex patterns.

This guide provides a rigorous, code-first method to force NGINX to bypass caching for specific dynamic routes using Apache's mod_headers and SetEnvIf directives within .htaccess.

The Architecture: Why NGINX Ignores Your Code

To fix the problem, we must understand the topology. SiteGround, like many managed WordPress hosts, uses a reverse proxy architecture:

  1. Client Request → NGINX (Reverse Proxy/Cache)
  2. NGINX → Apache (Backend Server/Application)
  3. Apache → PHP/WordPress

When NGINX Direct Delivery or Dynamic Cache is active, NGINX inspects the incoming request. If a cached version exists in memory (Memcached/NGINX RAM), it serves that content immediately. The request never reaches Apache.

Consequently, PHP-based logic (like nocache_headers() in WordPress) never executes because the application layer is never touched. The only way to communicate with NGINX is to ensure that when the cache is primed (the first visit), Apache sends specific HTTP headers instructing NGINX never to store that response.

The Solution: Header Manipulation via .htaccess

We cannot edit nginx.conf in a shared or cloud managed environment. However, NGINX is configured to respect upstream Cache-Control headers sent by Apache.

We will use a combination of regex matching on the Request_URI and conditional header setting to strictly forbid caching for specific routes.

Step 1: Identify the Regex Pattern

Assume you have a React dashboard mounted at /app/. You need to exclude:

  • /app/dashboard
  • /app/user/123/settings
  • /app/cart?id=xyz

A standard wildcard like /app/* often fails in GUI settings depending on how query strings are handled. The regex we want is ^/app/.*.

Step 2: Implement the Exclusion Rule

Open the .htaccess file in your web root (public_html). Insert the following block at the very top of the file, before the # BEGIN WordPress block. This ensures these headers are processed before any WordPress routing logic takes over.

<IfModule mod_headers.c>
    <IfModule mod_setenvif.c>
        # 1. Match the Request URI using Regex
        # Matches any URL starting with /app/, /cart, or /checkout
        SetEnvIf Request_URI "^/(app|cart|checkout)/.*$" NO_CACHE_ROUTE

        # 2. Match Specific API Endpoints (e.g., WP JSON Namespace)
        # Useful for Headless WP setups using standard REST API
        SetEnvIf Request_URI "^/wp-json/my-namespace/v1/dynamic-data.*$" NO_CACHE_ROUTE

        # 3. Apply Cache-Kill Headers conditionally
        # These headers tell NGINX (and the browser) not to store the response
        Header set Cache-Control "private, no-cache, no-store, must-revalidate" env=NO_CACHE_ROUTE
        Header set Pragma "no-cache" env=NO_CACHE_ROUTE
        Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT" env=NO_CACHE_ROUTE
        
        # 4. Explicit SiteGround Cache Bypass (Proprietary Header)
        # This header explicitly signals the SG NGINX layer to bypass
        Header set X-SG-Cache "Bypass" env=NO_CACHE_ROUTE
    </IfModule>
</IfModule>

Code Analysis

  • SetEnvIf: This sets an internal environment variable NO_CACHE_ROUTE only if the regex matches the incoming URI. This prevents the performance penalty of setting headers on every single image or CSS file.
  • Cache-Control: private, no-store: private prevents shared proxies (like Cloudflare) from caching it. no-store instructs the browser and NGINX not to write the file to disk/memory.
  • X-SG-Cache: This is specific to SiteGround’s infrastructure. While Cache-Control is usually sufficient, explicitly setting the SG bypass header guarantees the NGINX layer drops the object.

Client-Side Validation: React Implementation

Even with server-side headers configured, modern frontend frameworks can aggressively cache data in the browser or via state managers (Redux/Zustand/React Query).

To ensure your frontend respects the new "live" data nature of these endpoints, use the following useFreshData hook pattern. This uses the native fetch API with standard ES2024 practices.

import { useState, useEffect } from 'react';

interface FetchResult<T> {
  data: T | null;
  loading: boolean;
  error: Error | null;
}

/**
 * A hook to fetch data that explicitly bypasses browser cache.
 * Useful for shopping carts or user sessions.
 */
export function useFreshData<T>(url: string): FetchResult<T> {
  const [data, setData] = useState<T | null>(null);
  const [loading, setLoading] = useState<boolean>(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    const abortController = new AbortController();

    const fetchData = async () => {
      try {
        setLoading(true);
        
        // Append a timestamp nonce to ensure the browser strictly requests a new version
        // This is a failsafe against aggressive local browser caching
        const nonceUrl = new URL(url, window.location.origin);
        nonceUrl.searchParams.append('_t', Date.now().toString());

        const response = await fetch(nonceUrl.toString(), {
          method: 'GET',
          headers: {
            'Content-Type': 'application/json',
            // Explicitly request no cache interaction
            'Cache-Control': 'no-cache',
            'Pragma': 'no-cache'
          },
          cache: 'no-store', // Interaction mode for the cache
          signal: abortController.signal,
        });

        if (!response.ok) {
          throw new Error(`Network response was not ok: ${response.status}`);
        }

        const result = await response.json();
        setData(result);
      } catch (err) {
        if (err instanceof Error && err.name !== 'AbortError') {
          setError(err);
        }
      } finally {
        setLoading(false);
      }
    };

    fetchData();

    return () => {
      abortController.abort();
    };
  }, [url]);

  return { data, loading, error };
}

Deep Dive: How the Bypass Propagates

It is vital to understand the propagation flow to debug future issues.

  1. The Miss: When a user visits /app/dashboard for the first time (or after cache expiry), NGINX has no copy. It forwards the request to Apache.
  2. The Tag: Apache matches the regex ^/app/.*. It attaches Cache-Control: no-store and X-SG-Cache: Bypass to the response object.
  3. The Handshake: Apache sends this response back to NGINX.
  4. The Decision: NGINX inspects the headers. It sees no-store. Instead of saving this HTML/JSON to its RAM (Dynamic Cache), it streams the data directly to the client and discards the copy.
  5. The Client: The browser receives the headers. When the user navigates away and back (using the Back button), the no-store header forces the browser to re-request the page from the server rather than loading from disk cache.

Common Pitfalls and Edge Cases

1. Query String vs. Request URI

Apache's Request_URI variable usually matches the path before the query string.

  • Correct: Request_URI "^/cart$" matches /cart and /cart?id=1.
  • Incorrect: Trying to match Request_URI "^/cart\?id=.*" will fail. If you need to exclude based on a query parameter (e.g., exclude only if ?nocache=true is present), use THE_REQUEST or QUERY_STRING:
# Exclude if query string contains 'debug_mode=true'
SetEnvIf Query_String "debug_mode=true" NO_CACHE_ROUTE

2. HTTPS Protocol Overhead

Ensure your regex does not include the protocol or domain. Request_URI is strictly the path component.

  • Bad: SetEnvIf Request_URI "https://example.com/app/.*" ...
  • Good: SetEnvIf Request_URI "^/app/.*" ...

3. Order of Operations

If you are using WordPress, WordPress handles 404s by routing everything through index.php. If your custom route does not actually exist as a file, Apache hands it to WordPress. The headers set via .htaccess persist through this handoff. However, if a WordPress plugin later sends a header("Cache-Control: public") via PHP, it might override your Apache headers depending on server configuration (though Apache mod_headers usually wins if configured with always or standard set).

To be absolutely safe, verify headers via curl:

curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app/dashboard

Look specifically for x-proxy-cache: MISS or x-proxy-cache: BYPASS. If you see HIT, the .htaccess rule is either incorrect, placed too low in the file, or overridden by a conflicting NGINX config (rare on shared hosting).

Conclusion

Relying on "auto-detect" features for caching in complex React/WordPress hybrid environments is a recipe for state inconsistency. By leveraging the underlying Apache-NGINX relationship and manually injecting control headers via regex, you gain deterministic control over your application's data freshness. This approach bypasses the limitations of PHP-level plugins and communicates directly with the infrastructure layer.

Labels: