Die Adresse der Seite war an zwei Stellen gepflegt: E-Mails nutzten NEXT_PUBLIC_SITE_URL, alles SEO-Relevante dagegen ein fest verdrahtetes "https://" + siteConfig.domain (16 Stellen, darunter eine roh eingetippte "https://wabenhain.com" im Produkt-JSON-LD). Laeuft der Shop unter einer anderen Domain als wabenhain.com — Staging, Vorschau-Host, spaeterer Domainwechsel, der im k8s-Ingress hinterlegte Host — zeigten damit sitemap.xml, robots.txt, saemtliche Canonical-Tags und alle strukturierten Daten geschlossen auf eine fremde Adresse. Google verwirft eine Sitemap mit fremden Hosts, und ein Canonical auf eine andere Domain weist die Indexierung aktiv von der echten Seite weg. Jetzt eine einzige Quelle: getSiteUrl() in lib/url.ts, mit siteConfig.domain als Rueckfallebene, damit eine vergessene Umgebungsvariable nicht "http://localhost:3000" in einer oeffentlichen Sitemap landen laesst. getBaseUrl() bleibt als Alias fuer den in E-Mail-Code eingebuergerten Namen und liefert denselben Wert. robots.ts bekommt dabei "force-dynamic" (wie sitemap.ts es schon hatte): ohne das rendert Next.js die Datei beim Build statisch vor und backt den Wert ein, den NEXT_PUBLIC_SITE_URL genau dann hatte. Im Docker-Build ist die Variable nicht gesetzt — die Sitemap-Zeile waere also dauerhaft auf dem Rueckfallwert eingefroren. Gegen einen laufenden Produktions-Build geprueft: robots.txt, sitemap.xml, Canonical-Tags und JSON-LD folgen jetzt alle dem zur Laufzeit gesetzten Wert. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
37 lines
1.5 KiB
TypeScript
37 lines
1.5 KiB
TypeScript
import { siteConfig } from "@/lib/site-config";
|
|
|
|
/**
|
|
* Oeffentliche Basis-URL der Seite, ohne abschliessenden Schraegstrich
|
|
* (z.B. "https://wabenhain.com").
|
|
*
|
|
* EINZIGE Quelle fuer absolute Links — sowohl fuer E-Mails (Bestellbestaetigung,
|
|
* Newsletter-Opt-in, Passwort-Reset) als auch fuer alles, was Suchmaschinen
|
|
* sehen: metadataBase/Canonicals (app/layout.tsx), sitemap.xml, robots.txt und
|
|
* saemtliche JSON-LD-Bloecke.
|
|
*
|
|
* Vorher war das auf zwei Quellen verteilt: E-Mails nutzten
|
|
* NEXT_PUBLIC_SITE_URL, SEO-relevante Stellen dagegen ein fest verdrahtetes
|
|
* "https://" + siteConfig.domain. Laeuft die Seite unter einer anderen Domain
|
|
* (Staging, Vorschau-Host, spaeterer Domainwechsel), zeigten Sitemap,
|
|
* Canonical-Tags und strukturierte Daten damit geschlossen auf eine fremde
|
|
* Adresse: Google verwirft eine Sitemap mit fremden Hosts, und Canonicals auf
|
|
* eine andere Domain weisen die Indexierung aktiv von der echten Seite weg.
|
|
*
|
|
* siteConfig.domain bleibt als Rueckfallebene erhalten, damit eine vergessene
|
|
* Umgebungsvariable in Produktion nicht zu "http://localhost:3000" in einer
|
|
* oeffentlichen Sitemap fuehrt.
|
|
*/
|
|
export function getSiteUrl(): string {
|
|
const configured = process.env.NEXT_PUBLIC_SITE_URL?.trim();
|
|
if (configured) return configured.replace(/\/+$/, "");
|
|
return `https://${siteConfig.domain}`;
|
|
}
|
|
|
|
/**
|
|
* Alias von getSiteUrl() unter dem in E-Mail-Code eingebuergerten Namen.
|
|
* Beide liefern denselben Wert — der Unterschied ist rein sprachlich.
|
|
*/
|
|
export function getBaseUrl(): string {
|
|
return getSiteUrl();
|
|
}
|