letsweb.biz
PL/EN Porozmawiajmy

Blog

9 fundamentów SEO, których potrzebuje każda strona małej firmy

Tomasz Kuśmierczyk & Claude ·

Większość porad o „SEO” jest albo ogólnikowa („pisz dobre treści”), albo topi Cię w checklistach na 200 punktów. To jest przeciwieństwo: konkretne, techniczne fundamenty, których naprawdę potrzebuje strona małej firmy — na przykładzie zmian, które niedawno wprowadziłem na realnej, dwujęzycznej (polsko-angielskiej) stronie zbudowanej w Astro.

Żadna z nich to nie jest „growth hack”. To hydraulika. Zrób je dobrze, a wyszukiwarki znajdą, zrozumieją i poprawnie pokażą Twoje strony. Pomiń je, a nawet świetne treści będą radzić sobie gorzej, niż mogłyby.

1. Mapa witryny (sitemap)

Mapa witryny (sitemap.xml) to czytelna dla maszyn lista wszystkich stron, które chcesz mieć zaindeksowane. Bez niej Google odkrywa strony wyłącznie przez podążanie za linkami — wolniej i mniej niezawodnie, zwłaszcza w przypadku nowszych serwisów.

Najprostsza mapa witryny to po prostu lista adresów:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
  </url>
  <url>
    <loc>https://example.com/blog/</loc>
  </url>
</urlset>

Przy stronie dwujęzycznej dochodzi bonus: w każdym wpisie możesz zadeklarować wersje językowe danej strony, dzięki czemu Google wie, że polska i angielska wersja to ta sama strona w dwóch językach, a nie dwa niezależne adresy.

Wskazówka: Jeśli strona jest mała (kilka stabilnych podstron), ręcznie napisana statyczna mapa witryny w zupełności wystarczy — bez wtyczek i kroków w buildzie.

2. Plik robots.txt

Maleńki plik, który każdy robot czyta jako pierwszy. Mówi, co wolno indeksować, i wskazuje lokalizację mapy witryny. To standardowy sygnał, który potwierdza, że indeksowanie jest dozwolone, i ogłasza, gdzie leży sitemap.

Minimalny plik pozwala wszystkim robotom i wskazuje mapę witryny:

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

3. hreflang — najważniejsza poprawka dla strony wielojęzycznej

Jeśli udostępniasz te same treści w dwóch językach, musisz powiedzieć Google, co jest czym. Każda strona deklaruje swoje odpowiedniki:

<link rel="alternate" hreflang="pl" href="https://example.com/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Te tagi <link> umieszcza się w <head> dokumentu, obok <title> i adresu kanonicznego — nigdy w <body>, gdzie zostaną zignorowane. (Hreflang można też zadeklarować nagłówkiem HTTP Link: albo wewnątrz mapy witryny XML; jedna metoda wystarczy.)

W kontekście <head> strony wygląda to tak:

<!doctype html>
<html lang="pl">
  <head>
    <title>…</title>
    <link rel="canonical" href="https://example.com/" />
    <link rel="alternate" hreflang="pl" href="https://example.com/" />
    <link rel="alternate" hreflang="en" href="https://example.com/en/" />
    <link rel="alternate" hreflang="x-default" href="https://example.com/" />
  </head>
  <body>…</body>
</html>

Zasada, która często sprawia kłopot: każda strona w zestawie językowym musi wymieniać wszystkie wersje łącznie z samą sobą, a odwołania muszą być wzajemne — jeśli polska strona wskazuje angielską, to angielska musi wskazywać polską, inaczej Google je zignoruje.

Obie strony deklarują ten sam zestaw odnośników — każda wskazuje na siebie i na drugą:

<!-- https://example.com/  (wersja polska) -->
<html lang="pl">
  <head>
    <link rel="alternate" hreflang="pl" href="https://example.com/" />
    <link rel="alternate" hreflang="en" href="https://example.com/en/" />
  </head>
</html>

<!-- https://example.com/en/  (wersja angielska) -->
<html lang="en">
  <head>
    <link rel="alternate" hreflang="pl" href="https://example.com/" />
    <link rel="alternate" hreflang="en" href="https://example.com/en/" />
  </head>
</html>

Bez hreflang dzieją się dwie złe rzeczy: Google może potraktować Twoje dwie wersje językowe jako zduplikowaną treść konkurującą ze sobą, a do tego może pokazać użytkownikowi niewłaściwy język. Z hreflang polski użytkownik dostaje polską stronę, a angielski — angielską.

4. Adresy kanoniczne (canonical)

Tag kanoniczny mówi Google, który adres jest tym jedynym, oficjalnym dla danej strony:

<link rel="canonical" href="https://example.com/en/" />

Ta sama strona często jest dostępna pod kilkoma adresami — www kontra goła domena, z ukośnikiem na końcu lub bez, z parametrami śledzącymi. Canonical scala to wszystko w jeden adres, żeby Twoje sygnały rankingowe się nie rozpraszały. Dobrze współgra z przekierowaniem 301 www → goła domena po stronie serwera.

5. Unikalne tytuły i opisy dla każdej strony

Częsty błąd: podstrony (np. polityka prywatności) dziedziczą <title> i meta description ze strony głównej, przez co kilka stron rości sobie ten sam tytuł. Zduplikowane tytuły zaburzają ranking i źle wyglądają w wynikach wyszukiwania.

Każda strona powinna mieć własny tytuł i opis, które opisują tę konkretną stronę. To podstawowa dobra praktyka, którą łatwo przeoczyć, gdy strony współdzielą jeden szablon układu.

6. Open Graph i karty Twittera

Te tagi sterują Twoim podglądem w social media — tym, co się pojawia, gdy ktoś udostępni Twój link na LinkedIn, Slacku, Facebooku czy X:

<meta property="og:title" content="…" />
<meta property="og:description" content="…" />
<meta property="og:image" content="…" />
<meta property="og:url" content="…" />

Bez nich udostępniony link pokazuje się jako goły adres bez obrazka. Z nimi zamienia się w porządną kartę z tytułem, opisem i grafiką — dużo bardziej klikalną.

Wskazówka: Idealny obraz społecznościowy ma 1200×630. Jeśli masz tylko kwadratowe logo, użyj typu karty summary (mała miniatura) zamiast summary_large_image, który niezgrabnie obramuje kwadrat.

7. Dane strukturalne (JSON-LD)

Dane strukturalne to mały blok JSON opisujący Twoją firmę w słowniku, który wyszukiwarki rozumieją (schema.org):

<script type="application/ld+json">
{ "@type": "ProfessionalService", "name": "…", "founder": {…}, "areaServed": "PL" }
</script>

Zamiast kazać Google domyślać się, kim jesteś, z samego tekstu, mówisz to wprost: nazwa firmy, właściciel, kontakt, obsługiwane języki. Może to dać bogatsze wyniki wyszukiwania i coraz częściej zasila asystentów AI odpowiadających na pytania o firmy.

8. Dopasuj widoczną treść do swojego pozycjonowania

Pomijając tagi techniczne, Twój widoczny nagłówek H1 i akapit wprowadzający to mocne sygnały rankingowe — i powinny odzwierciedlać to, co faktycznie oferujesz. Jeśli nagłówek mówi jedno, a Twoja firma zdążyła zmienić kierunek, popraw nagłówek. Na stronie wielojęzycznej zadbaj, by oba języki mówiły to samo.

To nie jest meta tag, ale to wciąż SEO: wyszukiwarki oceniają strony po tym, co na nich faktycznie jest.

9. Szybkość i prywatność: hostuj czcionki u siebie

Szybkość strony (Core Web Vitals) to realny czynnik rankingowy. Częstym winowajcą są blokujące renderowanie czcionki ładowane z zewnętrznego dostawcy. Hostowanie czcionek u siebie usuwa to blokujące żądanie oraz eliminuje przekazywanie danych do podmiotu trzeciego — zysk dla prywatności, który dodatkowo upraszcza politykę prywatności.

Podsumowanie

Żadna z tych rzeczy nie jest wyrafinowana. To fundamenty: mapa witryny i robots.txt, żeby dało się Cię zindeksować, hreflang i adresy kanoniczne, żeby właściwa wersja każdej strony była zrozumiana, unikalne tytuły, żeby strony nie konkurowały same ze sobą, Open Graph i dane strukturalne, żeby dobrze się prezentować, oraz treść, która uczciwie odpowiada temu, co robisz.

Zrób to raz, porządnie, a przeskoczysz poprzeczkę, której zaskakująco wiele stron małych firm nigdy nie przeskakuje.

← Wróć na blog

Komentarze