SEO dla stron na Vercel

W skrócie: Vercel daje Ci szybki TTFB, automatyczny HTTPS i optymalizację obrazów prosto z pudełka — to lepsza baza pod SEO niż większość platform hostingowych. Ale daje Ci też adresy URL preview deploymentów, które Google może zaindeksować, edge caching serwujący nieaktualne meta tagi i cold starty funkcji serverless, które spowalniają crawlery. Oto jak prawidłowo skonfigurować Vercel pod SEO, uniknąć pułapek, które widzę na co dzień, i wykorzystać edge do rzeczy, które faktycznie pomagają w pozycjonowaniu.

Vercel robi dla SEO więcej, niż myślisz

Lee Robinson, VP of Developer Experience w Vercel, pisał obszernie na blogu Vercel o tym, jak ISR wypełnia lukę między generowaniem statycznym w czasie budowania a renderowaniem w czasie działania. I ma rację — w przypadku stron z tysiącami podstron ISR oznacza, że nie musisz wybierać między szybkością a aktualnością. Dostajesz jedno i drugie.

Mimo to "dobre domyślne ustawienia" nie znaczy "zero pracy". Widziałem mnóstwo stron na Vercel z doskonałymi Core Web Vitals i fatalnym SEO — stron, gdzie każda metryka Lighthouse świeci na zielono, a każdy meta description jest pusty. Infrastruktura jest solidna. Konfiguracja to miejsce, gdzie ludzie popełniają błędy.

Konfiguracja SEO specyficzna dla Vercel

Pułapki SEO na Vercel, o których nikt Cię nie ostrzega

Tu zaczynam być kategoryczny. To problemy, które widzę na niemal każdej stronie Vercel, którą audytujemy. To nie są przypadki brzegowe — to domyślne ustawienia, które się mszczą.

Szczerze mówiąc, fakt, że Vercel nie obsługuje większości z tego domyślnie, jest zdumiewający.

Adresy URL preview deploymentów w indeksie Google

W zeszłym roku napisał do mnie klient, zdezorientowany. Wyszukiwanie jego marki zwracało stronę pod adresem their-project-git-feature-auth-fix-theirteam.vercel.app zamiast ich właściwej domeny. Nigdy wcześniej nie słyszeli o tym adresie. Nikt z ich zespołu go nigdzie nie udostępnił — a przynajmniej tak im się wydawało.

Okazało się, że trzy miesiące wcześniej programista wkleił link do preview w komentarzu do pull requesta na GitHubie. Googlebot znalazł go przez publiczne indeksowanie GitHuba. A ponieważ preview serwowało identyczną treść jak produkcja pod inną domeną, Google musiał wybrać, którą wersję zaindeksować. Wybrał źle.

To najczęstsza katastrofa SEO na Vercel, jaką widzę. Każdy branch, który wypchniesz, tworzy deployment pod adresem typu your-project-git-feature-branch-yourteam.vercel.app. Każdy pull request dostaje preview. Każdy commit na main dostaje deployment. Te adresy URL są publiczne, crawlowalne i jeden przypadkowo wklejony link od trafiania do indeksu Google.

Rozwiązanie:

1. Użyj edge middleware (pokazanego wyżej), żeby dodać X-Robots-Tag: noindex, nofollow do wszystkich żądań na .vercel.app.
2. W next.config.js dynamicznie ustawiaj kanoniczny URL na podstawie środowiska.
3. Ustaw NEXT_PUBLIC_SITE_URL jako zmienną środowiskową i używaj jej w metadanych — nigdy nie wpisuj domeny na sztywno.

// app/layout.tsx (lub gdziekolwiek definiujesz metadane)
export const metadata = {
  metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL || 'https://example.com'),
  alternates: {
    canonical: './',
  },
};

(Dlaczego Vercel po prostu nie dodaje X-Robots-Tag: noindex do preview deploymentów domyślnie? Pytałem. Bez odpowiedzi.) O ile mogę stwierdzić, to świadoma decyzja — adresy URL preview są przydatne do dzielenia się z interesariuszami. Ale koszt SEO jest realny i większość zespołów nie zdaje sobie z niego sprawy, dopóki nie zobaczy adresów vercel.app w Search Console. Barry Schwartz opisywał ten schemat na Search Engine Roundtable — wyciekanie stagingowych i preview URL-i do indeksu Google nie jest unikalne dla Vercel, ale model Vercel z automatycznym preview na każdy branch sprawia, że dzieje się to częściej i na większą skalę niż na jakiejkolwiek innej platformie.

Edge caching serwujący nieaktualne meta tagi

// pages/api/revalidate.ts
export default async function handler(req, res) {
  const { path, secret } = req.query;
  if (secret !== process.env.REVALIDATION_SECRET) {
    return res.status(401).json({ message: 'Invalid secret' });
  }
  await res.revalidate(path);
  return res.json({ revalidated: true });
}

Potrzebujesz tego endpointu. Oto dlaczego.

Jeśli używasz ISR lub agresywnych wartości s-maxage, edge cache Vercel może serwować nieaktualne strony z przeterminowanymi meta tagami przez godziny, a nawet dni. Aktualizujesz tytuł wpisu blogowego w CMS, ale wersja w cache na edge nadal ma stary tytuł. Google crawluje wersję z cache. Twoja aktualizacja tagu tytułowego nigdy nie zostaje odnotowana.

Podepnij ten endpoint rewalidacji do webhooka w CMS. Zmiany treści powinny wywoływać natychmiastowe czyszczenie cache, a nie czekać na następny cykl ISR. To nie jest opcjonalne.

W zeszłym miesiącu spędziłem dwie godziny na ustaleniu, dlaczego meta descriptions klienta się nie aktualizują. Rozwiązanie to... właściwie powinienem Ci najpierw pokazać błędne podejście. Mieli s-maxage=604800 — pełen tydzień edge cachingu — bez webhooka do rewalidacji. Każda edycja w CMS była niewidoczna dla Google przez siedem dni. Faktyczne rozwiązanie to jeden nagłówek Cache-Control w vercel.json i podpięcie powyższego webhooka. Dwie godziny na jeden nagłówek.

Cold starty funkcji serverless

Funkcje serverless Vercel mają cold starty. Jeśli funkcja nie była wywoływana od jakiegoś czasu, pierwsze żądanie uruchamia nową instancję — dodając 200–1000ms do czasu odpowiedzi. A jeśli Googlebot uderzy w 50 stron w szybkiej sekwencji i połowa z nich to cold starty, Twój crawl rate spada.

Powinienem być tu szczery — nie zmierzyłem dokładnego wpływu cold startów na budżet crawlowania z naukową rygorem. W sesji Google Search Central z 2024 roku John Mueller zauważył, że wolne serwery nie obniżają bezpośrednio pozycji, ale wpływają na to, ile stron Google crawluje na sesję. W naszych danych strony z TTFB poniżej 200ms są crawlowane mniej więcej o 40% częściej. Ale dla 50-stronicowej witryny marketingowej? Pewnie bez znaczenia. Dla ponad 10 000 stron to zupełnie inna historia — i właśnie tu cold starty zaczynają się kumulować w realny problem z budżetem crawlowania, który możesz faktycznie zmierzyć w raporcie statystyk crawlowania w Search Console.

Sposoby na złagodzenie problemu: używaj runtime edge dla stron SSR, kiedy to możliwe (prawie zerowe cold starty), używaj ISR do serwowania stron statycznych na edge i trzymaj funkcje serverless małe. Serio.

robots.txt i końcowe slashe: dwie poprawki w jednej linijce

Te dwie rzeczy są wstydliwie proste, więc łączę je w jedną sekcję. Obie powodują realne problemy. Obie naprawisz w sześćdziesiąt sekund.

robots.txt: Większość stron na Vercel serwuje ten sam robots.txt wszędzie — na produkcji, w preview, w developmencie. Preview powinny blokować całe crawlowanie. Użyj VERCEL_ENV (ustawianego automatycznie przez Vercel) do rozróżnienia:

// app/robots.ts (Next.js App Router)
import { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  const isProduction = process.env.VERCEL_ENV === 'production';

  if (!isProduction) {
    return {
      rules: { userAgent: '*', disallow: '/' },
    };
  }

  return {
    rules: { userAgent: '*', allow: '/' },
    sitemap: `${process.env.NEXT_PUBLIC_SITE_URL}/sitemap.xml`,
  };
}

Końcowe slashe: Jeśli trailingSlash nie jest ustawiony, zarówno /about, jak i /about/ prowadzą do tej samej treści bez przekierowania. To dwa adresy URL dla jednej strony. Google widzi oba. Rozwiązanie:

module.exports = {
  trailingSlash: false, // albo true — po prostu wybierz jedno
};

Po jednej linijce. O robots.txt nauczyłem się na własnej skórze na stronie klienta, która miała 47 zaindeksowanych adresów URL preview, zanim ktokolwiek to zauważył. Za każdym razem ta sama historia.

Rzeczy, które spodziewałem się być problemami, ale nimi nie były

Nie wszystko w SEO na Vercel to pole minowe. Kilka rzeczy, na które się przygotowywałem, a które okazały się w porządku:

• Hydratacja po stronie klienta a indeksowanie. Zakładałem, że niezgodności hydratacji w Next.js zmylą Googlebota. Nie mylą. Renderer Google radzi sobie z hydratacją Reacta bez problemu — treść jest w początkowej odpowiedzi HTML i to właśnie ona jest indeksowana. Błędy hydratacji to problem UX, nie SEO.
• Opóźnienie edge functions przy przekierowaniach. Spodziewałem się, że przekierowania na poziomie edge w vercel.json dodadzą odczuwalne opóźnienie w porównaniu z przekierowaniami Nginx. Różnica jest pomijalna — poniżej 5ms w każdym teście, jaki przeprowadziłem. Edge Vercel jest wystarczająco szybki, żeby to nie stanowiło problemu.
• Nieaktualna treść ISR podczas regeneracji. Kiedy ISR serwuje przestarzałą stronę podczas regeneracji w tle, obawiałem się, że Google zaindeksuje nieaktualną wersję w złym momencie. W praktyce okno stale-while-revalidate jest na tyle krótkie, że to nie ma znaczenia. Google crawluje na tyle rzadko, że musiałbyś mieć kosmicznego pecha, żeby Cię to ugryzło.
• Automatyczna kompresja Vercel. Testowałem, czy kompresja Brotli/gzip Vercel wpływa na to, jak Google parsuje HTML. Nie wpływa. Googlebot radzi sobie ze skompresowanymi odpowiedziami bez problemu. Zmarnowałem na to całe popołudnie.

Next.js + Vercel — konfiguracja SEO (najczęstsza kombinacja)

Z naszego doświadczenia zdecydowana większość stron hostowanych na Vercel działa na Next.js. Oto konkretna konfiguracja, która ma znaczenie dla SEO w tej kombinacji.

Przekierowania: next.config.js vs vercel.json

Przekierowania możesz zdefiniować w obu miejscach. Działają inaczej:

Moja zasada: używaj vercel.json do stałych migracji URL (przekierowania 301 ze starych ścieżek na nowe). Używaj middleware do warunkowych przekierowań wymagających logiki w czasie działania (geolokalizacja, testy A/B, uwierzytelnianie). Używaj przekierowań next.config.js tylko wtedy, gdy potrzebujesz funkcji specyficznych dla Next.js, takich jak obsługa basePath.

Dla stron z tysiącami przekierowań (częste po migracji domeny) trafisz w limit 1024. W takim przypadku użyj middleware z mapą przekierowań wczytywaną z pliku JSON lub bazy danych.

Generowanie sitemapy z ISR

Statyczne sitemapy się psują, gdy używasz ISR, ponieważ nowe strony mogą być generowane w czasie działania. Potrzebujesz dynamicznej sitemapy, która odzwierciedla aktualny stan Twoich treści.

// app/sitemap.ts (Next.js App Router)
import { MetadataRoute } from 'next';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = process.env.NEXT_PUBLIC_SITE_URL;

  // Pobierz wszystkie opublikowane strony z CMS
  const pages = await getAllPublishedPages();

  return pages.map((page) => ({
    url: `${baseUrl}${page.slug}`,
    lastModified: page.updatedAt,
    changeFrequency: page.type === 'blog' ? 'weekly' : 'monthly',
    priority: page.slug === '/' ? 1.0 : 0.8,
  }));
}

// Ta trasa rewaliduje się co godzinę
export const revalidate = 3600;

revalidate = 3600 na dole oznacza, że Vercel cachuje tę sitemapę na edge przez jedną godzinę, a potem ją regeneruje. Twoja sitemapa jest szybka dla crawlerów, ale odzwierciedla ostatnie zmiany w treściach. I to jedna z tych rzeczy, o których łatwo zapomnieć, dopóki Google nie zacznie ignorować stron opublikowanych trzy tygodnie temu, bo nigdy nie trafiły do sitemapy.

Generowanie obrazów OG na edge

Biblioteka @vercel/og generuje obrazy Open Graph w locie za pomocą edge functions. To ma znaczenie dla SEO, ponieważ obrazy OG wpływają na współczynnik klikalności w mediach społecznościowych, co pośrednio wpływa na Twój profil linków.

Nie będę udawał, że obrazy OG bezpośrednio wpływają na pozycje w Google. Nie wpływają. Ale wpływają na to, jak Twoje treści się rozprzestrzeniają, co wpływa na backlinki, co wpływa na pozycje. Łańcuch jest realny, nawet jeśli bezpośredni sygnał nie istnieje.

Warte 20 minut na konfigurację? Tak.

Konfiguracja metadanych

Next.js na Vercel obsługuje eksport metadata w App Router. Używaj go na każdej stronie:

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [`/api/og?title=${encodeURIComponent(post.title)}`],
    },
    alternates: {
      canonical: `/blog/${params.slug}`,
    },
  };
}

Tag canonical jest obowiązkowy. Każda strona go potrzebuje. Zapobiega problemom z duplikacją treści, które prześladują strony na Vercel z wieloma adresami URL deploymentów. A jeśli myślisz "dodam kanoniczne tagi później" — nie dodasz, a zanim sobie przypomnisz, Google zdąży zaindeksować trzy wersje Twojej strony głównej na trzech różnych subdomenach vercel.app.

Vercel na tle konkurencji pod kątem SEO

Vercel to nie jedyna nowoczesna platforma hostingowa. Oto jak wypada na tle alternatyw pod kątem funkcji istotnych dla SEO. Na podstawie naszych danych z audytów stron na wszystkich czterech platformach:

*Czasy budowania różnią się drastycznie w zależności od frameworka, ilości treści i planu cenowego — traktuj te wartości jako przybliżone.

Szczera ocena: Cloudflare Pages ma najlepszą surową wydajność edge (Workers mają prawie zerowe cold starty, a 300+ lokalizacji edge bije wszystkich). Vercel ma najlepsze doświadczenie deweloperskie i integrację z Next.js. Netlify to solidny złoty środek. Tradycyjny hosting daje najwięcej kontroli, ale wymaga najwięcej konfiguracji.

Pod kątem czystego SEO — czyli crawlowalności, szybkości i dostarczania treści — Cloudflare Pages technicznie wygrywa infrastrukturą. Ale Vercel wygrywa ogólnym przepływem pracy. Model ISR, preview deployments do testowania zmian SEO i ścisła integracja z Next.js oznaczają mniej błędów SEO w praktyce. Właściwie to nie do końca fair wobec Vercel — Netlify ma ten sam problem z indeksowaniem preview URL-i, a Cloudflare Pages nie ma natywnego ISR w ogóle. W wątku na Hacker News pod koniec 2023 roku porównującym kompromisy SEO platform hostingowych, dobrze uchwycono ten dylemat: deweloperzy wciąż wybierali Vercel dla DX, a potem spędzali tygodnie na naprawianiu problemów SEO, które nie istniałyby na tradycyjnym serwerze. Trawa jest zawsze bardziej zielona po drugiej stronie.

Guillermo Rauch, CEO Vercel, mówił o filozofii "zero-config" — ideę, że platforma powinna robić właściwe rzeczy bez pytania. W kwestii wdrożeń i DX to prawda. W kwestii SEO to wciąż aspiracja.

Mogę się mylić co do porównania kosztów. Cennik Vercel zmienia się często, a plany enterprise są nieprzejrzyste. Sprawdź aktualne ceny przed podjęciem decyzji na dużą skalę.

Jak SEOJuice współpracuje ze stronami na Vercel

Zbudowaliśmy SEOJuice, żeby obsługiwać to, czego platformy hostingowe nie robią — meta tagi, linkowanie wewnętrzne, schema markup, cotygodniowe audyty, które wyłapują dokładnie te pułapki opisane w tym artykule. Jeden tag script w Twoim <head>, działa z każdą stroną na Vercel. Tyle w kwestii pitchu. (Jeśli właśnie przeskoczyłeś do tej sekcji z Google, rozumiem. To ta część, która się liczy.)

FAQ

Czy Vercel automatycznie zajmuje się SEO?

Nie.

Zajmuje się infrastrukturą — szybki hosting, HTTPS, optymalizacja obrazów, dostarczanie na edge. To fundament. Ale meta tagi, przekierowania, linkowanie wewnętrzne, tagi canonical, blokowanie preview URL? To wszystko na Twojej głowie. Pytanie zakłada, że "platforma hostingowa" i "narzędzie SEO" to to samo. Nie są.

Czy Vercel jest lepszy od Netlify pod kątem SEO?

To pytanie zakłada, że platforma jest zmienną, która ma znaczenie. Nie jest. Widziałem fatalne SEO na Vercel, Netlify i Cloudflare Pages — i doskonałe SEO na wszystkich trzech. Vercel ma lepsze ISR i ściślejszą integrację z Next.js. Netlify ma bardziej przewidywalny cennik. Cloudflare Pages ma najszybszy edge. Ale prawdziwe różnice w SEO wynikają z tego, jak konfigurujesz platformę, a nie jaki logo jest na fakturze za hosting.

Powinienem używać vercel.json czy next.config.js do przekierowań?

Używaj vercel.json do stałych migracji URL — wykonują się na edge przed uruchomieniem Twojej aplikacji, co jest szybsze. Używaj middleware Next.js do warunkowych przekierowań wymagających logiki w czasie działania (geotargetowanie, sprawdzanie uwierzytelnienia). Używaj next.config.js tylko wtedy, gdy potrzebujesz funkcji routingu specyficznych dla Next.js. I nie rozdzielaj tych samych przekierowań między wiele plików konfiguracyjnych — wybierz jedno źródło prawdy na typ przekierowania.

Podsumowanie

Vercel to jedna z najlepszych platform hostingowych pod kątem SEO w 2026 roku — nie dlatego, że robi SEO za Ciebie, ale dlatego, że usuwa przeszkody infrastrukturalne, które utrudniają SEO na tradycyjnym hostingu. Szybki TTFB, automatyczny HTTPS, optymalizacja obrazów, ISR, preview deployments do testowania. To dobry fundament.

Ale pułapki specyficzne dla platformy są realne. Najbardziej frustruje mnie to, że większość z nich to luki konfiguracyjne, które Vercel mógłby zamknąć lepszymi domyślnymi ustawieniami — nagłówek noindex na preview deploymentach, wymuszony wybór końcowego slasha przy tworzeniu projektu, ostrzeżenie, gdy Twój robots.txt jest identyczny we wszystkich środowiskach — ale zamiast tego platforma optymalizuje pod kątem doświadczenia deweloperskiego i zostawia SEO jako kwestię do odkrycia dopiero wtedy, gdy Google zaindeksuje coś, czego nie powinien. Poznaj te pułapki. Skonfiguruj się wokół nich.

Jeśli prowadzisz stronę na Vercel i chcesz zobaczyć, jak naprawdę wygląda Twoje SEO, uruchom darmowy audyt. Wyłapie zduplikowane adresy URL, brakujące meta tagi i luki konfiguracyjne, których panel Vercel Ci nie pokaże.