---
title: "Hosting Platforms - Serpwise Documentation"
description: "Set up domains hosted on Vercel, Netlify, GitHub Pages, and other platforms to work with the Serpwise proxy."
url: "https://serpwise.ai/docs/hosting-platforms/"
source: "https://serpwise.ai/docs/hosting-platforms/"
---
[Back to Serpwise](/)

Serpwise Documentation

Connect · Configure · Execute

Search documentation

`/`

No documentation found.

↑↓ Navigate Enter to open

Browse documentation

When your website is hosted on a platform like Vercel, Netlify, or GitHub Pages, some extra configuration is needed to route traffic through Serpwise without triggering DNS conflict warnings.

## Why DNS Conflicts Happen

Hosting platforms assign custom domains via DNS (CNAME or A records). When you point DNS to Serpwise instead, the hosting platform no longer sees traffic arriving and may show warnings like “Invalid Configuration” or “Domain not verified.”

This is an inherent DNS constraint - a domain can only point to one destination. It is not a bug or misconfiguration.

## The Solution: Deployment URL as Origin

Instead of using the domain’s IP address as the origin, use the hosting platform’s **deployment URL**:

1. ### Find your deployment URL
   
   Every platform assigns a permanent URL to your project (e.g. `your-project.vercel.app`, `your-site.netlify.app`).
2. ### Set it as Origin Host
   
   In Serpwise domain settings, enter the deployment URL as the **Origin Host** and **Origin Host Header**.
3. ### Point DNS to Serpwise
   
   Create a CNAME record for your domain pointing to your Serpwise proxy endpoint.
4. ### Remove the custom domain from the platform
   
   This eliminates “Invalid Configuration” warnings since the platform no longer needs to manage the domain.

## Platform Guides

Vercel Netlify GitHub Pages Render Railway

1. In Vercel Dashboard, go to your project’s **Settings &gt; Domains**
2. Note your `.vercel.app` URL (e.g. `my-project.vercel.app`)
3. In Serpwise:
   
   - **Origin Host**: `my-project.vercel.app`
   - **Origin Host Header**: `my-project.vercel.app`
   - **Protocol**: HTTPS, **Port**: 443
4. Update DNS: `yourdomain.com CNAME {proxy-subdomain}.edge.serpwise.ai`
5. Remove `yourdomain.com` from Vercel’s domain settings

<!--THE END-->

1. In Netlify Dashboard, go to **Site configuration &gt; Domain management**
2. Note your `.netlify.app` URL (e.g. `my-site.netlify.app`)
3. In Serpwise:
   
   - **Origin Host**: `my-site.netlify.app`
   - **Origin Host Header**: `my-site.netlify.app`
   - **Protocol**: HTTPS, **Port**: 443
4. Update DNS: `yourdomain.com CNAME {proxy-subdomain}.edge.serpwise.ai`
5. Remove `yourdomain.com` from Netlify’s domain settings

<!--THE END-->

1. Your GitHub Pages URL is `{username}.github.io` or `{org}.github.io/{repo}`
2. In Serpwise:
   
   - **Origin Host**: `{username}.github.io`
   - **Origin Host Header**: `{username}.github.io`
   - **Protocol**: HTTPS, **Port**: 443
3. Update DNS: `yourdomain.com CNAME {proxy-subdomain}.edge.serpwise.ai`
4. Remove the custom domain from your repository’s **Pages settings**

<!--THE END-->

1. Your Render service URL is `{service-name}.onrender.com`
2. In Serpwise:
   
   - **Origin Host**: `{service-name}.onrender.com`
   - **Origin Host Header**: `{service-name}.onrender.com`
   - **Protocol**: HTTPS, **Port**: 443
3. Update DNS and remove the custom domain from Render

<!--THE END-->

1. Your Railway deployment URL is `{project}.up.railway.app`
2. In Serpwise:
   
   - **Origin Host**: `{project}.up.railway.app`
   - **Origin Host Header**: `{project}.up.railway.app`
   - **Protocol**: HTTPS, **Port**: 443
3. Update DNS and remove the custom domain from Railway

## Why Use Serpwise as a Proxy?

Some hosting platforms discourage reverse proxies. Here’s what Serpwise actually provides:

| Benefit         | Details                                                                                                                                               |
|-----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Performance** | Edge-level HTML modification without origin code changes or deployments. No additional latency beyond standard proxy overhead (typically under 10ms). |
| **Security**    | Exploit path blocking, bot detection, and request filtering at the edge. Security headers injected before responses reach visitors.                   |
| **Analytics**   | Per-request logging with full request/response metadata. Bot vs. human traffic breakdown and rule match tracking.                                     |
| **SEO Control** | Real-time meta tags, canonicals, structured data, and header modifications. No code deployments needed - changes apply instantly.                     |

## Proxy Identification Headers

Serpwise adds the following headers to origin requests so hosting platforms can identify the real client:

| Header              | Purpose                                           |
|---------------------|---------------------------------------------------|
| `X-Forwarded-For`   | Visitor’s real IP address - standard proxy header |
| `X-Forwarded-Proto` | Protocol used by the visitor (`https`)            |
| `X-Forwarded-Host`  | The hostname requested by the visitor             |

These headers ensure your origin application can access accurate client information even though requests arrive through the proxy.

Serpwise deliberately does **not** add custom branded headers (e.g. `X-Serpwise-*`) on requests to origin - custom proxy identifiers are pattern-matched by anti-bot systems (Imunify360, Cloudflare, DataDome) and can degrade your origin’s WAF reputation scoring.