Nginx reverse proxy for Snoika pages

You need two location blocks in your existing `server` block. The first sends Snoika's pages to Snoika's origin with `proxy_pass`. The second leaves every other request on your current backend. Snoika's team supplies the origin and the configuration values, so the placeholders below are the only parts you change.

server {
    listen 443 ssl;
    server_name example.com;

    # Pages Snoika manages (prefix and origin from Snoika's team)
    location ^~ <SNOIKA_PAGE_PREFIX> {
        proxy_pass https://<SNOIKA_ORIGIN>;
        proxy_set_header Host <SNOIKA_ORIGIN_HOST>;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_ssl_server_name on;
    }

    # Every other request: existing site, unchanged
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
    }
}

Nginx is one of several supported proxy setups. Others include a Cloudflare Worker and AWS CloudFront with Lambda@Edge, and Snoika prepares a custom setup on request. Your code and hosting stay exactly as they are.

The `^~` modifier matters here. It tells Nginx to stop searching once this prefix matches, so the regex blocks further down your config never get a look at Snoika's requests.

Whether `proxy_pass` rewrites the path depends on one detail: whether you put a URI after the host. If you write `proxy_pass https://origin;` with no path, Nginx forwards the original request path untouched. If you write `proxy_pass https://origin/;` with a trailing slash, Nginx swaps the matched location prefix for that slash.

That one character decides whether Snoika's origin receives the full path or a shortened one. Use the form Snoika's team specifies. Also, a regex location can't carry a URI in `proxy_pass`, and Nginx refuses to load a config that tries. When you set the origin through a variable, add a `resolver` line so Nginx can look up the hostname at runtime.

Set `Host` to the origin hostname Snoika's team gives you, and pass your public domain in `X-Forwarded-Host`. By default Nginx sends the hostname from the `proxy_pass` line. Plenty of configs override that with `$host`, though, and the origin then receives a domain it doesn't recognize. You'll see that as a 404 or a TLS mismatch.

`proxy_ssl_server_name on` sends the right name during the TLS handshake (SNI), which HTTPS origins need. `X-Forwarded-Proto` tells the origin the visitor arrived over HTTPS, so generated links don't fall back to plain HTTP. Check one rendered page and confirm its canonical URL shows your domain.

Give Snoika's stylesheets and scripts their own proxied location so they don't fall through to your existing site. Route its images through that location too. A Snoika page loads files from paths outside its page prefix. Without a matching block, `location /` catches those requests, and your backend returns a 404.

Ask Snoika's team for the asset prefix and add it as a second `^~` block with the same `proxy_pass` and `Host` lines. Leave Snoika's cache headers alone unless you have a reason to change them. Then open a page with your browser's network panel and confirm every file returns 200 from the proxied path.

Run `nginx -t` before every reload, since it catches syntax errors and illegal `proxy_pass` URIs. Then reload with `nginx -s reload` and request a Snoika page straight from the server:

curl -I -H "Host: example.com" https://127.0.0.1<SNOIKA_PAGE_URL> -k

A 200 response with Snoika's headers confirms the routing works. Then request a normal page from your site and confirm nothing about it changed. To test in a browser before DNS points anywhere new, map your domain to the server in your hosts file.

Check the extras that travel with each page as well. Every page Snoika publishes carries schema markup and a canonical URL. Each page also carries Open Graph tags and internal links, with an entry in the sitemap. It also has a Markdown twin for AI crawlers and an `llms.txt` index. Request the Markdown twin and the `llms.txt` file through your domain, because crawlers only find them if the proxy serves them.

For the final check, confirm that pages cited in AI answers show your domain. Snoika tracks ChatGPT and Google AI Overviews, and it records the pages each one cites along with mentions and citations. If a cited URL shows your domain, the proxy is serving pages the way crawlers see them.

Tracking runs week by week, so give new pages a few cycles before you judge. Share of voice and competitor positions show whether the pages are gaining ground. Prompts come from your content map, and you can add custom prompts for the queries you care about.

Your next step is to get your origin and configuration values from Snoika's team, then add the two location blocks to a staging server first. Once the routes test clean, you can schedule finished pages, or schedule AI content generation with automatic publishing for pages that don't need review. You still approve every page in the dashboard. Snoika builds page templates that match your site and sets up GA4 and Google Tag Manager events, so you can track the leads from each page. Snoika runs the Nginx reverse proxy as a whole-site connection with human review on top. Connect Nginx.

See every platform Snoika connects to in all integrations.