Jak wybrać firmę do stworzenia strony internetowej

Wybór partnera do projektu strony internetowej rzadko psuje się na designie. Najczęściej psuje się dużo wcześniej: na złym briefie, niejasnym zakresie, obietnicach SEO bez pokrycia i braku planu po publikacji. Ten artykuł pokazuje, jak oceniać wykonawcę na podstawie kryteriów, które naprawdę zmniejszają ryzyko projektu — niezależnie od budżetu, terminu i technologii.

Założenia, wstęp i kontekst decyzji

Na potrzeby tego artykułu przyjmijmy trzy nieokreślone założenia wejściowe:

To ważne, bo jak wybrać wykonawcę strony zależy przede wszystkim od tego, czy budujesz prostą stronę ofertową, rozbudowany serwis treściowy, sklep, portal klienta czy system z integracjami. W aktualnej dokumentacji Google nie ma jednej „magicznej" technologii pod SEO; Google wyjaśnia, że większość platform może działać dobrze dla wyszukiwania, o ile wdrożenie jest poprawnie przygotowane przed startem, a przy frameworkach intensywnie używających JavaScript trzeba szczególnie pilnować zasad JS SEO.

Stan źródeł użytych w tym tekście to 20 maja 2026 r. Podstawą są: WCAG 2.2 W3C, opublikowane 5 października 2023 r. i zaktualizowane 12 grudnia 2024 r.; aktualna dokumentacja Google Search Essentials z grudnia 2025 r.; aktualne wytyczne Google dotyczące danych strukturalnych, zaktualizowane 6 stycznia 2026 r.; materiały web.dev dla Core Web Vitals oraz PWA; OWASP Top 10:2025; oraz polskie przepisy z 2019 i 2024 r. dotyczące dostępności cyfrowej.

W tym sensie dobra firma do stworzenia strony internetowej nie jest „od ładnych layoutów", tylko od dostarczenia działającego produktu cyfrowego. GOV.UK Service Standard streszcza to bardzo trzeźwo: trzeba rozumieć użytkowników i ich potrzeby, rozwiązywać cały problem, zapewniać spójne doświadczenie między kanałami, upraszczać korzystanie z usługi i dbać, by każdy mógł z niej korzystać. To są bardzo dobre kryteria także dla prywatnych projektów webowych, nawet jeśli nie budujesz usługi publicznej.

Kryteria oceny wykonawcy

Kompetencje techniczne i architektura wdrożenia

Na poziomie technicznym pytanie nie brzmi: „czy robią w WordPressie / Next.js / Shopify?", tylko: „czy potrafią dobrać technologię do celu projektu?". Google podkreśla, że większość platform może działać dobrze dla SEO, ale tylko wtedy, gdy nowe wdrożenie jest prawidłowo skonfigurowane jeszcze przed publikacją; przy frameworkach JavaScript trzeba dodatkowo sprawdzić zgodność z praktykami JS SEO. Jeśli wykonawca nie umie wyjaśnić, dlaczego proponuje daną technologię, w jaki sposób rozwiąże indeksację, przekierowania, formularze, integracje i środowisko testowe, to nie proponuje architektury — proponuje preferencje własnego zespołu.

Dobra odpowiedź techniczna powinna obejmować przynajmniej: środowisko stagingowe, repozytorium kodu, procedurę wdrożeń, obsługę integracji, właściciela domeny i hostingu, plan backupów, możliwość rozwoju oraz zasady migracji URL-i, jeśli strona zastępuje poprzednią wersję. Google w poradniku o migracjach wyraźnie wskazuje, że zmiany adresów URL wymagają przygotowania mapowania starych i nowych adresów oraz przekierowań, aby ograniczyć negatywny wpływ na widoczność.

UX i praca na potrzebach użytkowników

Jeżeli wykonawca zaczyna spotkanie od koloru przycisku, a nie od użytkownika, celu i scenariusza konwersji, to ryzyko projektu rośnie. GOV.UK Service Standard zaczyna od zrozumienia użytkowników i ich potrzeb oraz od projektowania prostych, spójnych doświadczeń. To bardzo dobre sito przy wyborze agencji web, bo szybko oddziela zespoły procesowe od zespołów stricte produkcyjnych.

W praktyce warto oczekiwać, że wykonawca zapyta o to, kto używa strony, po co na nią wchodzi, co ma zrobić na urządzeniu mobilnym, jakie przeszkody napotyka dziś i które elementy strony są krytyczne biznesowo. Jeżeli użytkownik ma wysłać lead, zarejestrować się na wydarzenie, pobrać dokument, kupić produkt albo przejść przez płatność, to właśnie te przepływy powinny być osią projektu, a nie estetyka hero section.

SEO od etapu planowania, a nie po publikacji

Google pisze wprost, że dobrym momentem na zatrudnienie specjalisty SEO jest etap planowania nowej strony albo redesignu. Jednocześnie Google przypomina, że pojawianie się w wynikach organicznych nie kosztuje pieniędzy, a SEO nie polega na „kupieniu miejsca" w Google. Dlatego dobra oferta webowa nie obiecuje wyniku pozycyjnego, tylko opisuje, jak od początku buduje solidne podstawy: architekturę informacji, sensowne adresy URL, indeksowalne szablony, logiczne linkowanie wewnętrzne, meta dane, treść oraz pomiar po starcie.

W aktualnych Search Essentials Google wskazuje kilka podstawowych praktyk: tworzenie pomocnych treści, używanie słów, których ludzie realnie szukają, umieszczanie ich w istotnych miejscach — takich jak tytuł strony i główny nagłówek — oraz dbanie o crawlability linków i poprawne potraktowanie obrazów, danych strukturalnych i JavaScriptu. Jeżeli oferta mówi tylko „SEO-ready", ale nie wyjaśnia, co to oznacza technicznie i redakcyjnie, to warto założyć, że zakres jest niedookreślony.

Dostępność WCAG i zgodność z realiami prawnymi

W3C zaleca dziś używanie WCAG 2.2 przy tworzeniu i aktualizowaniu polityk oraz wdrożeń dostępności. To jest najbezpieczniejszy punkt odniesienia dla nowych projektów, nawet jeśli konkretne obowiązki prawne w danym przypadku odnoszą się do innych aktów lub sektorów. Dodatkowo W3C udostępnia osobne zestawienie zmian w WCAG 2.2, które obejmują m.in. kwestie widoczności fokusu, rozmiaru elementów klikalnych, drag-and-drop czy dostępnego uwierzytelniania.

W Polsce trzeba rozróżnić dwa porządki. Dla podmiotów publicznych od 2019 r. obowiązuje ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych. Z kolei od 28 czerwca 2025 r. obowiązuje ustawa z 26 kwietnia 2024 r. wdrażająca Europejski Akt o Dostępności dla określonych produktów i usług; gov.pl wskazuje, że obejmuje ona m.in. usługi handlu elektronicznego świadczone przez strony internetowe i urządzenia mobile, przy czym przewidziano również wyłączenia, w tym dla usług oferowanych lub świadczonych przez mikroprzedsiębiorcę. Z punktu widzenia firmy kupującej projekt oznacza to jedno: wykonawca powinien umieć odróżnić obowiązek prawny od dobrej praktyki projektowej i nie mieszać tych dwóch rzeczy.

To kryterium ma też bardzo praktyczny wymiar. WebAIM Million 2026 wykazał, że 95,9% badanych stron głównych miało wykrywalne błędy WCAG 2 A/AA, a najczęstsze problemy nadal dotyczą niskiego kontrastu, brakujących altów, brakujących etykiet formularzy, pustych linków i pustych przycisków. Jeżeli wykonawca nie potrafi opisać, jak testuje formularze, fokus klawiatury, strukturę nagłówków i teksty alternatywne, to deklaracja „robimy dostępne strony" jest zbyt słaba.

Mobilność i ewentualne PWA

Nie każda strona potrzebuje PWA, ale każda powinna być sensownie zaprojektowana mobilnie. web.dev definiuje PWA jako aplikację webową, która dzięki progressive enhancement może zapewniać większą niezawodność, integrację z urządzeniem i instalowalność, a jednocześnie działać z jednej bazy kodu na wielu urządzeniach. Z perspektywy zakupu usług webowych to ważne wtedy, gdy strona ma wyjść poza funkcję prezentacyjną i obsługiwać np. formularze terenowe, zgłoszenia, dokumenty, statusy czy pracę offline.

Jednocześnie trzeba uważać na uproszczenia. MDN przypomina, że service workery działają wyłącznie w bezpiecznym kontekście HTTPS, a osobny przewodnik MDN o instalowalności PWA wskazuje, że instalacja i zachowanie PWA zależą od spełnienia określonych wymagań technicznych oraz wsparcia w przeglądarce. Dobra firma do stworzenia strony internetowej nie będzie więc sprzedawała PWA „na wszelki wypadek", tylko pokaże, kiedy to rzeczywiście ma sens biznesowy.

Bezpieczeństwo, aktualizacje i kontrola zależności

Bezpieczeństwo strony nie zaczyna się od firewalla po ataku, tylko od decyzji projektowych. OWASP Top 10:2025 podkreśla, że lista odzwierciedla najistotniejsze ryzyka dla aplikacji webowych i została zaktualizowana o bieżące trendy, w tym problemy wynikające z łańcucha dostaw oprogramowania. Dla klienta kupującego stronę oznacza to bardzo praktyczne pytania: kto odpowiada za aktualizacje, jak zarządzane są zależności, czy jest środowisko testowe, jak wyglądają backupy, jak szybko reaguje się na awarię i czy są logi oraz monitoring.

Jeżeli projekt obejmuje formularze, logowanie, płatności albo dokumenty, bezpieczeństwo nie może być „opcją premium". Nawet prosta strona ofertowa powinna mieć procedurę aktualizacji, kontrolę dostępu i plan rollbacku. Jeśli wykonawca mówi, że „po wdrożeniu klient sobie poradzi", a jednocześnie buduje projekt na wielu wtyczkach i integracjach, to jest to czerwona flaga operacyjna.

Utrzymanie po starcie i zdolność przejęcia projektu

Strona internetowa nie jest zamkniętym plikiem PDF. Po publikacji zaczyna się etap aktualizacji, korekt treści, zmian funkcjonalnych i monitoringu wydajności. Dlatego jednym z podstawowych kryteriów przy pytaniu jak wybrać wykonawcę strony jest to, czy w ogóle przewiduje on wsparcie po starcie. Na własnych stronach SolidBee opisuje utrzymanie jako zestaw działań obejmujących aktualizacje, administrację, monitoring, backupy, bezpieczeństwo, rozwój funkcji i możliwość przejęcia istniejących projektów po innej firmie; przy usłudze webowej deklaruje też wsparcie po publikacji, w tym pierwszy miesiąc po wdrożeniu. To jest dobry przykład tego, jak powinien wyglądać jawny zakres opieki powdrożeniowej.

W praktyce dobrze jest wybierać partnera, który potrafi nie tylko zbudować nowy serwis, ale też przejąć odpowiedzialność za istniejący. To ogranicza ryzyko „vendor lock-in", czyli sytuacji, w której po roku nie da się rozwijać strony bez wracania do pierwotnego wykonawcy.

Proces projektowy, prototypowanie i QA

Dobry wykonawca powinien umieć pokazać proces przed sprzedażą, nie dopiero po podpisaniu umowy. Własny opis procesu na stronie SolidBee obejmuje analizę i strategię, projekt, implementację i opiekę powdrożeniową; na poziomie usługi webowej doprecyzowuje brief i analizę, UX/UI, implementację oraz publikację i wsparcie. Taki poziom jawności nie gwarantuje jeszcze jakości, ale pozwala ocenić dojrzałość operacyjną firmy.

Proces warto też oceniać przez to, czy przewiduje prototypy, testy formularzy, testy mobilne, weryfikację treści, kontrolę przekierowań i odbiór jakościowy. GOV.UK w swoim manuale projektowym traktuje prototypowanie jako narzędzie do zbierania feedbacku, a nie dekorację. W projektach komercyjnych logika jest taka sama: jeżeli klient pierwszy raz „widzi" produkt dopiero na produkcji, ryzyko kosztownych zmian rośnie.

Komunikacja, transparentność i zainteresowanie biznesem klienta

Google w poradniku „Do you need an SEO?" sugeruje bardzo dobre pytania rekrutacyjne wobec wykonawcy: czy pokaże wcześniejsze realizacje, jak mierzy sukces, jakie ma doświadczenie w branży, jak będzie komunikował postępy i czy udostępni pełną informację o zmianach oraz ich uzasadnieniu. Google radzi także sprawdzić, czy potencjalny partner jest naprawdę zainteresowany biznesem klienta — powinien pytać, co czyni ofertę unikalną, kim są klienci, jak firma zarabia i jakie ma kanały marketingowe.

To jest niezwykle praktyczne kryterium. Firma, która nie pyta o model biznesowy, najczęściej projektuje „pod szablon", a nie pod cel. Dobra komunikacja nie oznacza częstych meetingów, lecz jasną odpowiedzialność, opis etapów, komentarze do decyzji i porządną dokumentację zmian.

Budżet, zakres i wycena strony

Wycena strony bez briefu bywa myląca, bo w praktyce nie wycenia rozwiązania, tylko luźne wyobrażenie o nim. SolidBee komunikuje to dość uczciwie: koszt zależy od zakresu projektu, liczby podstron, funkcji, treści, integracji i wybranych rozwiązań, a wycena jest przygotowywana indywidualnie po briefie. To jest zdrowy model, bo odzwierciedla rzeczywisty wpływ złożoności na koszt.

Google uzupełnia tę perspektywę o drugi ważny element: oczekiwania. Według Google sensowna oferta SEO powinna zawierać realistyczne szacunki poprawy i nakładu pracy, a jeśli ktoś gwarantuje pierwsze miejsce w wynikach wyszukiwania — trzeba szukać innego partnera. Dobra wycena strony rozdziela więc to, co jest pewnym zakresem wykonawczym, od tego, co jest hipotezą biznesową po starcie.

Referencje, case studies i dowody wykonania

Portfolio bez kontekstu bywa równie mało użyteczne jak ładny Dribbble shot. Google zachęca, by sprawdzać referencje biznesowe i pytać poprzednich klientów, czy wykonawca był użyteczny, łatwy we współpracy i czy dawał pozytywne wyniki. Dodatkowo Google rekomenduje poprosić o techniczny i SEO-wy audyt oraz o realistyczną ocenę spodziewanych efektów jeszcze przed przyznaniem dostępu edycyjnego.

Dobre case study powinno pokazywać przynajmniej: problem wyjściowy, zakres prac, czas realizacji, narzędzia lub podejście, rezultat i rolę wykonawcy. Na stronach SolidBee widać taki układ w case'ach Aura Aerial oraz ZAZ NYSA, gdzie obok opisu wyzwania i rozwiązania pokazano też deklarowane efekty oraz czas realizacji. To nie zastępuje rozmowy z klientem referencyjnym, ale daje punkt startu do weryfikacji.

Umowy, prawa, dostęp do kont i SLA

Ten obszar jest regularnie niedoceniany, a to właśnie on rozstrzyga, czy po roku projekt da się bezpiecznie rozwijać. Google przypomina, że właściciel strony odpowiada za działania firm, które zatrudnia, i że jeśli wykonawca ma dostęp FTP lub serwerowy, powinien być gotów wyjaśnić wszystkie wprowadzane zmiany. To dobrze uzasadnia potrzebę zapisów umownych o dostępie, odpowiedzialności i transparentności.

W praktyce umowa powinna regulować co najmniej: prawa do projektu i kodu, właściciela domeny i hostingu, dostęp do repozytorium, dostęp do Search Console, GA4 i GTM, zasady zgłaszania zmian, terminy odpowiedzi, procedurę awarii, odpowiedzialność za backupy, warunki gwarancji oraz sposób zakończenia współpracy. SLA nie zawsze jest konieczne przy stronie wizytówkowej, ale dla serwisów leadowych, sklepów i projektów operacyjnych jest bardzo rozsądne.

Modele współpracy i budżet

Poniższa tabela nie jest cennikiem rynkowym, tylko ramą decyzyjną. Pokazuje, jak zwykle wygląda wybór agencji web albo innego modelu współpracy przy typowych projektach stron i serwisów biznesowych.

Jeżeli Twój budżet jest nieokreślony, zacznij nie od modelu, lecz od krytyczności projektu. Strona, która ma tylko prezentować ofertę i zbierać kilka leadów miesięcznie, nie wymaga tej samej organizacji co serwis, od którego zależy sprzedaż, obsługa wydarzeń, ruch organiczny albo dostępność prawna. Im większa odpowiedzialność biznesowa strony, tym bardziej opłaca się partner z procesem, QA, utrzymaniem i jasnymi odpowiedzialnościami.

Jeśli termin realizacji jest nieokreślony, to nie wybieraj najkrótszej obietnicy kalendarzowej. W projektach webowych „szybko" często oznacza: bez discovery, bez treści, bez planu migracji i bez testów. Taki zysk na starcie zwykle wraca jako koszt po wdrożeniu.

Zapytaj o bezpłatną wycenę →

Brief, pytania i proces współpracy

Jak przygotować brief strony www

Dobry brief strony www nie musi być długi, ale musi usuwać najważniejsze niewiadome. To właśnie on porządkuje zakres i poprawia wycenę strony. Google sugeruje, że dobry partner powinien pytać o unikalność oferty, klientów, model biznesowy, konkurencję i obecne kanały marketingowe, a SolidBee na etapie briefu i analizy deklaruje ustalanie celu projektu, grupy odbiorców i priorytetów.

Poniżej lista pytań, które warto samodzielnie uzupełnić jeszcze przed pierwszą rozmową:

Jak ocenić ofertę pod kątem SEO i marketingu

To jest moment, w którym najłatwiej odróżnić ofertę estetyczną od oferty biznesowej. Google Search Essentials wskazują, że skuteczność w wyszukiwarce opiera się na technicznych wymaganiach, politykach antyspamowych i kilku kluczowych praktykach, takich jak pomocne treści, sensowne słowa w ważnych miejscach strony oraz crawlable links. Z kolei Google w poradniku dla osób zatrudniających SEO wprost odradza kupowanie obietnic pierwszego miejsca i zachęca do oczekiwania dowodów, uzasadnień oraz realistycznych estymacji.

Dobra oferta SEO w projekcie strony powinna zawierać co najmniej:

Linkowanie wewnętrzne i crawlability

Google wyjaśnia, że używa linków jako sygnału trafności i do odnajdywania nowych stron do crawlowania. Jednocześnie zaznacza, że link powinien być przede wszystkim crawlable — standardowy element HTML <a> z atrybutem href — oraz mieć anchor text, który pomaga użytkownikom i Google zrozumieć treść strony docelowej. To oznacza, że oceniając ofertę, warto pytać nie tylko „czy zrobicie blog", ale „jak będą połączone strony usług z artykułami, case studies i formularzami kontaktu".

W praktyce dobra strona usługowa powinna mieć logiczne połączenie między ofertą, portfolio, blogiem i wyceną. To właśnie tym sposobem treści edukacyjne wspierają strony sprzedażowe, a silne strony główne przekazują sens tematyczny głębiej w serwis.

Dane strukturalne bez nadużyć

Google wyjaśnia, że używa danych strukturalnych do lepszego rozumienia treści strony i że poprawne wdrożenie może kwalifikować stronę do richer appearance w wynikach wyszukiwania. Jednocześnie Google podkreśla, że rekomendowanym formatem jest JSON-LD, że dane muszą reprezentować rzeczywistą, widoczną treść strony, oraz że nawet poprawne wdrożenie nie gwarantuje wyświetlenia rich results.

To bardzo ważne przy selekcji wykonawcy. Jeśli ktoś sprzedaje „schema = gwarancja gwiazdek i lepszych pozycji", to upraszcza temat ponad stan. Poprawne pytanie brzmi: jakie dane strukturalne mają sens dla naszej witryny i jak będziecie je walidować oraz mierzyć ich wpływ w Search Console?

Core Web Vitals i realne dane użytkowników

W 2026 roku stabilny zestaw Core Web Vitals to LCP, INP i CLS. web.dev wyjaśnia, że LCP mierzy odczuwalną szybkość ładowania głównej treści, INP — responsywność interakcji, a CLS — stabilność wizualną. Dobre progi to odpowiednio: LCP ≤ 2,5 s, INP ≤ 200 ms i CLS ≤ 0,1, oceniane na 75. percentylu odsłon. INP oficjalnie zastąpił FID jako Core Web Vital 12 marca 2024 r.

Trzeba jednak czytać te liczby właściwie. Google wyraźnie zaznacza, że Core Web Vitals są jednym z wielu aspektów i nie warto obsesyjnie reagować na drobne wahania pojedynczego pomiaru. web.dev dodaje, że dane laboratoryjne są ważne w developmencie, ale nie zastępują pomiaru field data; wręcz rekomenduje wdrożenie własnego real-user monitoringu, bo tylko dane z rzeczywistego użycia pokazują pełny obraz. Jeżeli oferta mówi wyłącznie o wyniku Lighthouse z dnia odbioru, to jest niepełna.

Sitemap, indeksacja i migracja

Google przypomina, że sitemap to przydatny sygnał, ale nadal jest tylko wskazówką, a nie gwarancją crawlowania. Równie ważne pozostają linkowanie wewnętrzne, brak blokad technicznych i poprawna indeksowalność. Przy nowej stronie lub redesignie wykonawca powinien pokazać, jak wygeneruje sitemap, jak ją zgłosi w Search Console oraz jak obsłuży robots.txt, canonicale i przekierowania.

To samo dotyczy migracji. Google wprost pisze, że przy zmianie adresów stare i nowe URL-e trzeba zmapować, a później wdrożyć przekierowania oraz testować efekt w Search Console. To nie jest detal techniczny „dla SEO-wca", tylko podstawowy element ochrony wartości biznesowej istniejącej witryny.

Jak oceniać frazy, treści i efekt marketingowy

Jeśli oferta przewiduje content, upewnij się, że wykonawca nie pracuje na poziomie „wrzucimy teksty z frazami". Search Essentials przypominają, że słowa używane przez użytkowników powinny pojawiać się w ważnych miejscach strony, ale całość musi nadal być pomocna, wiarygodna i people-first. To oznacza, że dobra oferta marketingowo-SEO powinna łączyć plan treści z architekturą strony i z procesem redakcyjnym, a nie traktować tekstu jako dodatku na końcu projektu.

Pakiet publikacyjny, checklista i FAQ

Jeśli chcesz od razu przełożyć te kryteria na praktykę, porównaj z tym, jak potencjalny partner opisuje swój proces i dowody wykonania. Na przykład SolidBee na stronie usługi webdev komunikuje responsywność, WCAG, CMS, szybkość i techniczne SEO, w Portfolio pokazuje case studies z opisem problemu, rozwiązania i efektu, a w formularzu wyceny projektu zaczyna od typu projektu, co jest rozsądnym punktem wyjścia do briefu i zakresu.

Jeżeli chcesz porozmawiać już nie o „stronie w ogóle", ale o Twoim konkretnym projekcie, najkrótsza ścieżka to: zobacz, jak SolidBee opisuje tworzenie stron i WCAG, przejrzyj Portfolio, a potem przejdź do wyceny projektu. Dzięki temu łatwiej porównać deklaracje procesowe z realną ofertą i zakresem pytań wejściowych.

Checklista przed podpisaniem umowy

Przed akceptacją oferty sprawdź, czy możesz zaznaczyć wszystkie poniższe pola:

Dwie najważniejsze pozycje na tej liście są bezpośrednio zgodne z ostrzeżeniami Google: sprawdzaj referencje, proś o realistyczny audyt oraz unikaj wykonawców gwarantujących topowe pozycje.