Vercel

Si votre site est déployé sur Vercel, vous pouvez diffuser votre documentation Jamdesk à l'adresse /docs sur votre propre domaine. Il existe deux façons de procéder, et les deux produisent le même résultat :

• Option A : réécritures vercel.json — sans code, fonctionne avec n'importe quel framework. La plupart des projets devraient commencer ici.
• Option B : Edge Middleware — pour les sites qui utilisent déjà Edge Middleware et souhaitent intégrer Jamdesk dans le même fichier.

Prérequis

• Un projet déployé sur Vercel
• Votre sous-domaine Jamdesk (disponible dans les paramètres du dashboard), avec l'option Héberger sur /docs activée
• Votre domaine personnalisé enregistré et vérifié dans le dashboard

Option A : réécritures vercel.json

Une réécriture peut changer la destination d'une requête, mais elle ne peut pas ajouter d'en-tête de requête — c'est pourquoi chaque destination porte à la place un marqueur public, ?jd_proxy=1, qui indique à Jamdesk que la requête est passée par votre proxy. Jamdesk le supprime avant le rendu ; vos visiteurs ne le voient jamais.

Créez ou modifiez vercel.json à la racine de votre projet, en remplaçant YOUR_SLUG par votre sous-domaine Jamdesk :

{
  "rewrites": [
    { "source": "/docs", "destination": "https://YOUR_SLUG.jamdesk.app/docs?jd_proxy=1" },
    { "source": "/docs/:path*", "destination": "https://YOUR_SLUG.jamdesk.app/docs/:path*?jd_proxy=1" },
    { "source": "/_next/:path*", "destination": "https://YOUR_SLUG.jamdesk.app/_next/:path*" },
    { "source": "/_jd/:path*", "destination": "https://YOUR_SLUG.jamdesk.app/_jd/:path*?jd_proxy=1" }
  ]
}

/_next/:path* n'a besoin d'aucun marqueur — c'est un chemin de ressources statiques que Jamdesk ne restreint jamais. Si votre site n'est pas une application Next.js, il n'a pas de fichiers /_next/ propres, donc la réécriture reste correcte : chaque requête sous ce chemin est simplement transmise à Jamdesk.

Les quatre mêmes règles fonctionnent dans next.config.js pour les projets Next.js :

/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    return [
      { source: "/docs", destination: "https://YOUR_SLUG.jamdesk.app/docs?jd_proxy=1" },
      { source: "/docs/:path*", destination: "https://YOUR_SLUG.jamdesk.app/docs/:path*?jd_proxy=1" },
      { source: "/_next/:path*", destination: "https://YOUR_SLUG.jamdesk.app/_next/:path*" },
      { source: "/_jd/:path*", destination: "https://YOUR_SLUG.jamdesk.app/_jd/:path*?jd_proxy=1" },
    ];
  },
};

export default nextConfig;

Transférez aussi vos fichiers racine

robots.txt, sitemap.xml, llms.txt et llms-full.txt se trouvent à la racine du domaine, en dehors de /docs — sans eux, les moteurs de recherche et les agents IA ne peuvent pas découvrir votre documentation. Si Jamdesk gère la racine de votre domaine, ajoutez quatre règles supplémentaires :

{
  "rewrites": [
    { "source": "/robots.txt", "destination": "https://YOUR_SLUG.jamdesk.app/robots.txt?jd_proxy=1" },
    { "source": "/sitemap.xml", "destination": "https://YOUR_SLUG.jamdesk.app/sitemap.xml?jd_proxy=1" },
    { "source": "/llms.txt", "destination": "https://YOUR_SLUG.jamdesk.app/llms.txt?jd_proxy=1" },
    { "source": "/llms-full.txt", "destination": "https://YOUR_SLUG.jamdesk.app/llms-full.txt?jd_proxy=1" }
  ]
}

Déployez et vérifiez

Déployez avec vercel --prod (ou effectuez un push vers votre dépôt Git connecté), puis ouvrez https://yoursite.com/docs et affichez le code source de la page. Vérifiez deux choses :

1. <link rel="canonical"> pointe vers votre domaine, pas vers YOUR_SLUG.jamdesk.app
2. Il n'y a aucune balise <meta name="robots" content="noindex">

Si l'un des deux est incorrect, une réécriture n'a pas son marqueur ?jd_proxy=1 — voir Pourquoi le marqueur est important.

Option B : Edge Middleware

Si vous utilisez déjà Edge Middleware, définissez-y l'en-tête de requête X-Jamdesk-Forwarded-Host plutôt que d'utiliser le marqueur. Les deux signaux sont équivalents — choisissez cette option uniquement si vous préférez conserver la logique de routage dans du code que vous maintenez déjà.

Créez un fichier middleware.ts à la racine de votre projet, en remplaçant YOUR_SLUG par votre sous-domaine Jamdesk :

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

const JAMDESK_HOST = 'YOUR_SLUG.jamdesk.app';

export function middleware(request: NextRequest) {
  const url = request.nextUrl;
  const destination = new URL(url.pathname + url.search, `https://${JAMDESK_HOST}`);

  // Clone headers and tell Jamdesk which domain the visitor actually used.
  const headers = new Headers(request.headers);
  headers.set('X-Jamdesk-Forwarded-Host', url.hostname);

  return NextResponse.rewrite(destination, {
    request: { headers },
  });
}

export const config = {
  matcher: ['/docs', '/docs/:path*', '/_jd/:path*'],
};

Le fichier doit s'appeler middleware.ts et exporter une fonction nommée middleware. Next.js 16 suggère de le renommer en proxy.ts, mais la production Vercel n'invoque pas encore proxy.ts — le renommer le désactive silencieusement.

Acheminez les ressources et les fichiers racine dans vercel.json

Les pages de Jamdesk chargent leurs bundles depuis /_next/, et les fichiers racine comme robots.txt se situent en dehors du matcher ci-dessus. Acheminez les deux avec des réécritures — les réécritures s'exécutent après la vérification du système de fichiers, donc votre propre résultat de build l'emporte toujours et seules les requêtes que votre site ne peut pas servir sont transmises à Jamdesk :

{
  "rewrites": [
    { "source": "/_next/:path*", "destination": "https://YOUR_SLUG.jamdesk.app/_next/:path*" },
    { "source": "/robots.txt", "destination": "https://YOUR_SLUG.jamdesk.app/robots.txt?jd_proxy=1" },
    { "source": "/sitemap.xml", "destination": "https://YOUR_SLUG.jamdesk.app/sitemap.xml?jd_proxy=1" },
    { "source": "/llms.txt", "destination": "https://YOUR_SLUG.jamdesk.app/llms.txt?jd_proxy=1" },
    { "source": "/llms-full.txt", "destination": "https://YOUR_SLUG.jamdesk.app/llms-full.txt?jd_proxy=1" }
  ]
}

Les fichiers racine portent ?jd_proxy=1 car le middleware ne s'exécute pas sur eux et une réécriture ne peut pas définir l'en-tête. Ajoutez-les uniquement si Jamdesk gère la racine de votre domaine — si votre site sert son propre robots.txt ou sitemap.xml, fusionnez-les plutôt.

Déployez et vérifiez

Déployez avec vercel --prod (ou effectuez un push vers votre dépôt Git connecté), puis ouvrez https://yoursite.com/docs et affichez le code source de la page. Vérifiez deux choses :

1. <link rel="canonical"> pointe vers votre domaine, pas vers YOUR_SLUG.jamdesk.app
2. Il n'y a aucune balise <meta name="robots" content="noindex">

Si l'un des deux est incorrect, l'en-tête X-Jamdesk-Forwarded-Host n'atteint pas Jamdesk — vérifiez que /docs figure dans le matcher.

Pourquoi le marqueur est important

Jamdesk a besoin d'un signal indiquant qu'une requête est arrivée via votre proxy plutôt que comme un accès direct à votre sous-domaine *.jamdesk.app. Le marqueur ?jd_proxy=1 et l'en-tête X-Jamdesk-Forwarded-Host portent tous deux ce signal, et Jamdesk les traite comme équivalents. L'un ou l'autre confirme votre domaine enregistré, fait pointer les liens canoniques, Open Graph et sitemap vers celui-ci, et permet à Domaine personnalisé uniquement de distinguer le trafic proxy des accès directs.

Un signal manquant échoue silencieusement — les pages s'affichent toujours, mais avec noindex et des canoniques de sous-domaine si aucun domaine personnalisé n'est enregistré, ou avec un échec de la vérification Domaine personnalisé uniquement si un domaine est enregistré. Une erreur 403 est le problème inverse : le signal est présent mais désigne un domaine qui n'est pas enregistré et actif pour ce projet.

Dépannage

Et ensuite ?