Vercel

Si votre site est déployé sur Vercel, vous pouvez servir votre documentation Jamdesk à /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 — aucun 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 veulent Jamdesk dans le même fichier.

Prérequis

• Un projet déployé sur Vercel
• Votre sous-domaine Jamdesk (dans les paramètres du dashboard), avec Host at a subpath activé
• 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 — chaque destination porte donc à la place un marqueur public, ?jd_proxy=1, qui indique à Jamdesk que la requête est passée par votre proxy. Jamdesk le retire 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 d'assets statiques que Jamdesk ne bloque jamais. Si votre site n'est pas une application Next.js, il n'a pas ses propres fichiers /_next/, donc la réécriture reste correcte : chaque requête sous ce chemin passe simplement à travers vers Jamdesk.

Les mêmes quatre 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 possède 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éployer et vérifier

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 YOUR_SLUG.jamdesk.app
2. Il n'y a pas de <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 au lieu d'utiliser le marqueur. Les deux signaux sont équivalents — choisissez cette option uniquement si vous préférez conserver la logique de routage dans un 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 — ce renommage le désactive silencieusement.

Acheminer les assets et les fichiers racine dans vercel.json

Les pages de Jamdesk chargent leurs bundles depuis /_next/, et les fichiers racine comme robots.txt se trouvent 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 sortie de build l'emporte toujours et seules les requêtes que votre site ne peut pas servir passent à 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 parce que le middleware ne s'exécute pas sur eux et qu'une réécriture ne peut pas définir l'en-tête. Ajoutez-les uniquement si Jamdesk possède la racine de votre domaine — si votre site sert son propre robots.txt ou sitemap.xml, fusionnez-les à la place.

Déployer et vérifier

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 YOUR_SLUG.jamdesk.app
2. Il n'y a pas de <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 est 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é, pointe les liens canonical, Open Graph et sitemap vers celui-ci, et permet à Domaine personnalisé uniquement de distinguer le trafic du proxy des accès directs.

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

Dépannage

Et ensuite ?