Landing page integration guide

RankAI builds the landing page. This guide shows how that page gets an address on your website.

There are three ways to connect it. Pick one before the first page goes live, and use that same setup for every page on the domain.

• DNS access. The page can be your homepage, or any other path on your site.

  https://yourdomain.com/ or https://yourdomain.com/virtual-try-on

• Routing in your app. You choose the path. Your team adds it in code.

  https://yourdomain.com/virtual-try-on

• Your own reverse proxy. Every page lives in a folder, such as /lp/.

  https://yourdomain.com/lp/virtual-try-on

Compare the options

Use this when you need a yes or no from your team. The sections below are the setup.

Option 1: Grant DNS access

This is the setup to use when landing pages are an ongoing part of the site. You give RankAI delegated access to the domain. We change the nameservers and manage the DNS from there. Publishing a page in RankAI then puts it live on your domain. Your team does not edit code, redeploy, or update a proxy for each page.

You still own the domain. It stays registered to you, in your name, at your registrar. RankAI manages the DNS that serves the landing pages.

RankAI only answers URLs that have a published landing page. Every other URL is passed through to the host that runs your site today. Your existing pages, checkout, app, and blog stay where they are.

You can publish a page at any path:

• The homepage: https://yourdomain.com/
• A top-level path: https://yourdomain.com/summer-offer
• A nested path: https://yourdomain.com/campaigns/q3

The slug is chosen in RankAI. It does not have to sit inside a folder, and it does not have to be added to your codebase.

What we need from you

1. Confirm this is the option you want.
2. Tell us the domain visitors should see, including whether you use yourdomain.com, www.yourdomain.com, or both.
3. Give RankAI delegated access at the registrar so we can change the nameservers. If you want to keep a login for the DNS, say so. We will create a Cloudflare account for the domain and make the changes there.
4. Tell us where the rest of the site is hosted today, so traffic that is not a landing page still reaches it.

If you want to keep a login

Delegated access is enough if RankAI should manage the DNS. If you want to open the records yourself, we create a Cloudflare account for the domain and make the changes on that account. The account is yours. You can sign in to it.

Cloudflare is used because yourdomain.com (the root domain, with nothing in front of it) needs CNAME flattening or an ALIAS record. A normal CNAME can point a name like www at another host. It cannot point the root domain, and many registrars do not offer CNAME flattening or an ALIAS record. Cloudflare does, which is why the nameservers are pointed there.

After setup

Publish or update a landing page in RankAI. The URL on your domain updates with it. Renaming a slug or unpublishing a page is the same: it happens from RankAI, with no deploy on your side.

Option 2: Route pages inside your app

Use this when your framework can proxy or rewrite a path, and you only expect a small number of landing pages. Next.js, Nuxt, SvelteKit, Remix, and a custom Node server can all do this. A hosted CMS that does not let you add server routes cannot.

Your app keeps serving the rest of the site. For each landing page, you add a route that fetches the page from RankAI and shows it at the path you choose. That path can be a top-level slug such as /virtual-try-on, as long as your app does not already use that path.

Every published, renamed, or removed page is a code change and a deploy. A page created in RankAI is not on your domain until that route ships. This stays manageable for a handful of URLs. It gets expensive once pages are added often.

Find your project ID

Open the project in RankAI. The project ID is the value in the address bar after /dashboard/. You will paste it into the route below in place of YOUR_PROJECT_ID.

Next.js

Add one rewrite per landing page in next.config.js (or next.config.mjs). The source is the URL on your site. The destination slug must match the slug in RankAI.

/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    const projectId = 'YOUR_PROJECT_ID';
    const origin = 'https://rankai.ai/api/hosted-landing';

    return [
      {
        source: '/virtual-try-on',
        destination: `${origin}/${projectId}/virtual-try-on`,
      },
      {
        source: '/summer-offer',
        destination: `${origin}/${projectId}/summer-offer`,
      },
    ];
  },
};

module.exports = nextConfig;

Deploy after you add or remove a rewrite. Visitors stay on your domain. The HTML is loaded from RankAI.

On another framework, do the same thing with that framework's rewrite or a server route: one path on your site, proxied to https://rankai.ai/api/hosted-landing/YOUR_PROJECT_ID/your-slug.

Option 3: Reverse-proxy a folder

Use this when you run Nginx or Apache in front of your site and you do not want to change DNS. One proxy rule covers every landing page, so a new page does not need a new config line or a deploy.

The tradeoff is the URL. Pages cannot use the homepage or a top-level path. Every landing page has to live under a folder you choose and keep, for example /lp/:

• Works: https://yourdomain.com/lp/virtual-try-on
• Does not work with this option: https://yourdomain.com/virtual-try-on
• Does not work with this option: https://yourdomain.com/

The folder is fixed. RankAI can still choose the last part of the path (the slug), but that slug is no longer free to sit anywhere on the domain. Tell us the folder you picked so the links RankAI generates use it.

Proxying the whole site (/) would send every request to RankAI and take your existing site offline. A single folder is what lets one rule cover future pages while the rest of the site stays on your server. A separate proxy rule per slug is option 2, with the same per-page maintenance.

Nginx

Put this in the server block for your domain. Replace YOUR_PROJECT_ID. The example uses /lp/. If you choose another folder, change both the location and tell RankAI.

location /lp/ {
    proxy_pass https://rankai.ai/api/hosted-landing/YOUR_PROJECT_ID/;
    proxy_ssl_server_name on;
    proxy_set_header Host rankai.ai;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

The trailing slash on proxy_pass matters. A request to /lp/virtual-try-on is forwarded as /virtual-try-on on the RankAI URL. Reload Nginx after you save the file.

Apache

Enable mod_proxy, mod_proxy_http, and SSL proxying, then add:

SSLProxyEngine on
ProxyPass        /lp/ https://rankai.ai/api/hosted-landing/YOUR_PROJECT_ID/
ProxyPassReverse /lp/ https://rankai.ai/api/hosted-landing/YOUR_PROJECT_ID/

Restart Apache after the change. A request to /lp/virtual-try-on is served from the RankAI page with that slug.

How to choose

• Choose option 1 if pages will be published more than occasionally, or if any page needs the homepage or a top-level URL with no further deploys.
• Choose option 2 if the list of pages is short, your framework can rewrite a path, and your team can deploy when that list changes.
• Choose option 3 if DNS cannot change, you already terminate traffic on Nginx or Apache, and every landing page URL can include a folder such as /lp/.

What to send RankAI

Reply with:

1. The option number.
2. The domain, and for option 3 the folder (for example /lp/).
3. For option 1, who can grant delegated access at the registrar. Tell us if you want to keep a login for the DNS. If you do, we create a Cloudflare account for the domain and make the changes there.