Relative URL (URL względny) to adres odnośnika zapisany bez podawania pełnej domeny – wskazuje lokalizację zasobu w stosunku do bieżącej strony lub głównego katalogu witryny. W przeciwieństwie do absolutnego URL-a, który zawiera protokół i domenę (np. https://przyklad.pl/oferta/), relative URL wygląda np. tak: /oferta/ lub ../oferta/. To pozornie mała różnica techniczna, która jednak może mieć realny wpływ na działanie linkowania wewnętrznego i indeksowanie strony.
Jak działają relative URL-e w praktyce?
Przeglądarka i wyszukiwarka interpretują relative URL, uzupełniając go o domenę oraz protokół aktualnie odwiedzanej strony. Jeśli użytkownik przegląda https://przyklad.pl/blog/ i napotka odnośnik ../kontakt/, przeglądarka automatycznie rozwiąże go do https://przyklad.pl/kontakt/. To wygodne rozwiązanie podczas tworzenia szablonów HTML, bo nie trzeba za każdym razem wpisywać pełnej ścieżki.
Rodzaje relative URL-i
- Względem katalogu głównego – zapis
/oferta/zawsze wskazuje na korzeń domeny, niezależnie od tego, w jakiej podstronie jesteśmy. - Względem bieżącej lokalizacji – zapis
produkt.htmllub./produkt.htmlwskazuje na plik w tym samym katalogu co aktualny dokument. - Względem katalogu nadrzędnego –
../kategoria/cofa się o jeden poziom w strukturze katalogów.
Absolute URL kontra Relative URL – porównanie
Oba typy adresów mają swoje zastosowania. Poniżej najważniejsze różnice:
- Absolute URL: pełna ścieżka (protokół + domena + ścieżka), zawsze jednoznaczny, odporny na błędy środowiskowe.
- Relative URL: krótszy zapis, łatwiejszy w utrzymaniu w dużych szablonach, ale może być błędnie interpretowany w pewnych okolicznościach.
Znaczenie dla SEO
Na pierwszy rzut oka relative URL to kwestia czysto techniczna, ale ma kilka newralgicznych konsekwencji dla pozycjonowania stron.
Problem zduplikowanej treści i przekierowań
Gdy witryna dostępna jest pod wieloma wariantami adresu (np. z www i bez, lub na http i https), relative URL-e mogą prowadzić Googlebot do różnych wersji tej samej strony. Jeśli robot zaindeksuje zasób raz z http://przyklad.pl/, a raz z https://przyklad.pl/, powstaje ryzyko duplikacji treści i rozproszenia sygnałów rankingowych (link juice). Właśnie dlatego w kontekście migracji HTTP→HTTPS lub zmiany domeny zaleca się stosowanie absolutnych URL-i – przynajmniej w canonicalach i sitemapach.
Crawl budget i indeksowanie
Googlebot podąża za linkami, rozwiązując relative URL-e na podstawie kontekstu strony. Jeśli baza strony (tag <base href>) jest źle skonfigurowana, robot może błędnie interpretować ścieżki i marnować crawl budget na nieistniejące lub powielone adresy. W większych witrynach e-commerce to poważny problem – kilkadziesiąt tysięcy źle rozwiązanych URL-i potrafi skutecznie zablokować indeksowanie nowych podstron.
Kanonizacja i tag canonical
Tag <link rel="canonical"> obsługuje zarówno relative, jak i absolutne URL-e. Google oficjalnie zaleca jednak używanie absolutnych adresów w canonicalach, bo eliminuje to wszelką niejednoznaczność. Relative URL w canonicalu działa poprawnie w większości przypadków, ale przy błędach konfiguracyjnych serwera lub CDN może zostać zinterpretowany inaczej, niż zakładał deweloper.
Linkowanie wewnętrzne
Relative URL-e są powszechnie stosowane w linkowaniu wewnętrznym i same w sobie nie szkodzą SEO – pod warunkiem, że struktura witryny jest spójna. Prawidłowe pozycjonowanie stron opiera się m.in. na spójnej siatce linków wewnętrznych, a niejednoznaczne ścieżki mogą powodować błędy 404 lub powielone adresy w logach serwera.
<base href> w połączeniu z relative URL-ami. Efektem jest sytuacja, w której wszystkie odnośniki na stronie wskazują na zupełnie inne zasoby niż zamierzył deweloper – a Google indeksuje setki adresów, które nigdy nie miały istnieć. Zanim wdrożysz relative URL-e na dużą skalę, sprawdź, czy Twój CMS lub framework poprawnie resolwuje ścieżki w każdym środowisku (dev, staging, produkcja).Sitemap i plik robots.txt
W pliku sitemap.xml Google bezwzględnie wymaga absolutnych URL-i. Relative URL-e w sitemapie są błędem – narzędzia dla webmasterów (Google Search Console) zgłoszą je jako nieprawidłowe wpisy i nie wezmą ich pod uwagę przy indeksowaniu. Podobnie w pliku robots.txt dyrektywy Disallow i Allow zapisuje się jako ścieżki względem domeny (czyli de facto w formie relative URL od katalogu głównego), co jest jednym z nielicznych wyjątków w oficjalnej specyfikacji.
Bezpieczeństwo i open redirect
Warto wspomnieć o aspekcie bezpieczeństwa: źle walidowane relative URL-e w aplikacjach webowych bywają wektorem ataku open redirect. To problem leżący po stronie programistycznej, ale pośrednio wpływa na SEO – Google może oznaczyć stronę jako niebezpieczną, co bezpośrednio przekłada się na widoczność w wynikach wyszukiwania.
Kiedy używać relative, a kiedy absolute URL?
Nie ma jednej, uniwersalnej odpowiedzi, ale w SEO przyjęła się praktyczna zasada:
- Relative URL – akceptowalny w linkach nawigacyjnych, menu, odnośnikach do zasobów statycznych (CSS, JS, obrazy) wewnątrz tej samej domeny.
- Absolute URL – obowiązkowy w tagach canonical, sitemapie XML, przekierowaniach 301 oraz wszędzie tam, gdzie treść jest syndykowana lub powielana na innych domenach.
Jeśli Twoja witryna działa wyłącznie na jednej domenie i ma poprawnie skonfigurowany HTTPS bez duplikatów www/non-www, relative URL-e w linkowaniu wewnętrznym nie zaszkodzą. Problemy pojawiają się przy migracjach, wielojęzycznych subdomenach lub architekturze headless CMS.
Chcesz mieć pewność, że linki wewnętrzne i konfiguracja URL-i w Twojej witrynie nie blokują jej wzrostu w Google? Zespół Webiti regularnie weryfikuje te aspekty w ramach kompleksowego audytu SEO – skontaktuj się z nami i sprawdź, co można poprawić.
