Google Cloud dla początkujących — praktyczny przewodnik krok po kroku. Jak zacząć, jak stawiać standalone HTML landing pages, mapować domenę i gdzie w tym wszystkim jest AI / Agent Platform
Short Answer
Google Cloud to platforma, na której możesz uruchamiać strony, aplikacje, narzędzia AI, bazy danych, agentów i automatyzacje bez kupowania własnego serwera. Dla Twojego zastosowania — szybkie, standalone landing pages pisane przez ChatGPT / Claude / Gemini — najpraktyczniejszy start to Cloud Shell + Cloud Run + Cloud Run Domain Mapping. Kod trzymasz jako prosty folder HTML/CSS/JS, pakujesz go w kontener Nginx, wdrażasz do Cloud Run jedną komendą, a potem podpinasz domenę lub subdomenę przez rekordy DNS u rejestratora, np. OVH. Cloud Run jest dobry do małych landingów, bo jest w pełni zarządzany, skaluje się automatycznie i może zejść do zera, gdy nikt nie odwiedza strony. Google opisuje Cloud Run jako platformę do szybkiego uruchamiania aplikacji i stron bez zarządzania infrastrukturą.
1. Co to jest Google Cloud?
Google Cloud to zestaw usług chmurowych Google. Możesz myśleć o nim jak o „centrum technicznym”, w którym uruchamiasz:
- strony internetowe,
- aplikacje,
- landing pages,
- API,
- bazy danych,
- storage plików,
- kontenery,
- funkcje serverless,
- modele AI,
- agentów AI,
- automatyzacje,
- analitykę danych,
- narzędzia developerskie.
Najważniejsze dla początkującego: nie musisz od razu znać całego Google Cloud. Do Twojego modelu pracy wystarczy opanować kilka elementów:
- Google Cloud Console — panel zarządzania.
- Project — kontener na usługi, billing i uprawnienia.
- Cloud Shell — terminal w przeglądarce.
- Cloud Shell Editor — edytor kodu w przeglądarce.
- Cloud Run — uruchamianie strony/aplikacji z kontenera.
- Domain Mapping — podpięcie domeny.
- Billing / Budgets — kontrola kosztów.
- IAM — uprawnienia użytkowników.
- Agent Platform — później, gdy chcesz budować agentów AI.
Cloud Shell jest szczególnie wygodny, bo ma już zainstalowany Google Cloud CLI, jest uwierzytelniony i zawiera edytor kodu, więc można budować, debugować i deployować aplikacje bez instalacji lokalnego środowiska na komputerze.
2. Dlaczego Google Cloud jest dobry do standalone landing pages?
Dla Twoich projektów typu:
- landing dla nowej usługi,
- mini-strona produktowa,
- narzędzie SEO/GEO,
- SearchBox GEO Lab,
- test niszy,
- strona kampanijna,
- prosta strona HTML bez WordPressa,
Google Cloud ma kilka zalet.
2.1. Nie potrzebujesz klasycznego hostingu
Nie konfigurujesz Apache, PHP, FTP, certyfikatów, panelu hostingowego ani ręcznego serwera VPS. Przy Cloud Run wdrażasz aplikację lub statyczną stronę jako kontener.
2.2. Możesz pracować w przeglądarce
Cloud Shell i Cloud Shell Editor działają w przeglądarce. Google wskazuje, że Cloud Shell Editor można uruchomić bezpośrednio z konsoli lub przez shell.cloud.google.com, a terminal otworzyć w tym samym środowisku.
2.3. Kod może pisać AI
ChatGPT / Claude / Gemini mogą wygenerować:
index.html,style.css,script.js,Dockerfile,nginx.conf,deploy.sh,- instrukcję deploya,
- poprawki UX,
- wersję mobile,
- formularz,
- schema.org,
- meta tags.
2.4. Możesz szybko testować nisze
Nie musisz od razu budować dużego WordPressa. Możesz uruchomić prostą stronę w stylu:
pomysł → kod HTML → deploy Cloud Run → subdomena → test ruchu / Ads / SEO / GEO
2.5. Cloud Run skaluje się automatycznie
Cloud Run jest w pełni zarządzany i może obsługiwać strony oraz aplikacje bez zarządzania infrastrukturą; Google wskazuje też, że Cloud Run może „scale to zero”, gdy nie ma ruchu.
3. Najważniejsze pojęcia dla początkującego
Project
Project to osobny kontener na wszystko: usługi, billing, uprawnienia, Cloud Run, logi i domeny.
Praktyczna zasada:
1 projekt = 1 większy serwis / marka / środowisko testowe
Przykład:
project-cobots-pl
project-geoknows-tools
project-rajnarzedzi
project-test-landingpages
Nie trzymaj wszystkich landingów, eksperymentów i agentów w jednym chaotycznym projekcie.
Billing Account
To konto rozliczeniowe. Google Cloud zwykle wymaga podpięcia płatności, nawet jeśli projekt mieści się w niskim zużyciu. Nowi klienci mogą otrzymać kredyty startowe — Google podaje na stronie Agent Platform / Google Cloud informację o kredytach do 300 USD dla nowych klientów.
Cloud Shell
Terminal w przeglądarce. Tu wpisujesz komendy:
gcloud run deploy
gcloud config set project
gcloud services enable
Cloud Shell ma już Google Cloud CLI i inne narzędzia, więc to najprostsza droga dla osoby, która nie chce instalować środowiska lokalnie.
Cloud Shell Editor
Edytor kodu w przeglądarce, podobny do VS Code. Możesz w nim tworzyć pliki:
index.html
style.css
script.js
Dockerfile
nginx.conf
deploy.sh
Cloud Run
Usługa serverless do uruchamiania kontenerów. Dla Ciebie oznacza to: „wrzucam folder ze stroną, Google buduje kontener i wystawia stronę pod adresem *.run.app”.
Google opisuje Cloud Run jako platformę do aplikacji i stron, gdzie można uruchamiać frontend, backend, batch jobs, hostować LLM-y i kolejki bez zarządzania infrastrukturą.
Domain Mapping
Podpięcie własnej domeny lub subdomeny do usługi Cloud Run. Google opisuje ten proces jako mapowanie domeny do usługi i aktualizację rekordów DNS; można mapować domenę główną, np. example.com, albo subdomenę, np. landing.example.com.
IAM
System uprawnień. Google zaleca zasadę least privilege — nie dawać szerokich ról typu Owner/Editor w produkcji, jeśli można użyć bardziej ograniczonej roli.
4. Jaką usługę wybrać do strony HTML?
Najprostszy wybór dla Ciebie: Cloud Run
Wybierz Cloud Run, gdy:
- strona jest standalone HTML/CSS/JS,
- chcesz mieć szybki deploy z Cloud Shell,
- chcesz mapować domenę,
- chcesz mieć możliwość dodania backendu później,
- chcesz budować mini-narzędzia, nie tylko statyczne strony,
- chcesz używać kontenerów,
- chcesz łatwo przenosić projekt.
Alternatywa: Firebase Hosting
Dobry wybór dla stricte statycznych stron, jeśli chcesz bardzo prosty hosting frontendowy, CDN i łatwe deploye. W tym poradniku skupiamy się jednak na Cloud Run, bo już z niego korzystasz.
Alternatywa: Cloud Storage static website
Możliwe, ale mniej wygodne przy SSL, domenach, aplikacjach i przyszłych mini-narzędziach.
Alternatywa: App Engine
Starszy, nadal użyteczny model, ale do Twoich szybkich landingów Cloud Run jest bardziej uniwersalny.
5. Minimalna architektura dla standalone landing page
Najprostszy projekt:
landing-cobots/
├── index.html
├── style.css
├── script.js
├── nginx.conf
├── Dockerfile
└── deploy.sh
Jak to działa:
index.html— strona.style.css— wygląd.script.js— proste interakcje.nginx.conf— Nginx słucha na porcie 8080, którego oczekuje Cloud Run.Dockerfile— pakuje stronę w kontener Nginx.deploy.sh— komenda wdrożenia.
Google Skills pokazuje analogiczny kierunek dla statycznej strony na Cloud Run: utworzenie Dockerfile, użycie Nginx, skopiowanie index.html do katalogu Nginx i wystawienie portu 8080.
6. Krok po kroku: pierwszy projekt Google Cloud
Krok 1: Wejdź do Google Cloud Console
Wejdź do:
https://console.cloud.google.com/
Zaloguj się kontem Google.
Krok 2: Utwórz projekt
W górnym pasku wybierz projekt albo kliknij New Project.
Nazwa przykładowa:
landing-cobots-pl
Project ID może być automatyczny, np.:
landing-cobots-pl-123456
Zapisz Project ID, bo będzie potrzebny w komendach.
Krok 3: Podłącz billing
Wejdź w:
Billing → Link a billing account
Bez billing account wiele usług nie zadziała. Od razu przejdź do Budgets & alerts i ustaw limit ostrzegawczy.
Google opisuje budżety jako sposób śledzenia faktycznych wydatków względem planowanego budżetu, z progami alertów wysyłanymi e-mailem.
Prosty start:
Budżet miesięczny: 50–100 zł
Alerty: 50%, 80%, 100%
Krok 4: Otwórz Cloud Shell
W prawym górnym rogu Cloud Console kliknij ikonę terminala:
Activate Cloud Shell
Albo wejdź bezpośrednio:
https://shell.cloud.google.com/
Cloud Shell otwiera terminal z gotowym gcloud.
Krok 5: Ustaw projekt w terminalu
W Cloud Shell wpisz:
gcloud config set project TWOJ_PROJECT_ID
Przykład:
gcloud config set project landing-cobots-pl-123456
Sprawdź:
gcloud config get-value project
Krok 6: Włącz potrzebne API
Dla Cloud Run i budowania z kodu zwykle potrzebujesz:
gcloud services enable run.googleapis.com
gcloud services enable cloudbuild.googleapis.com
gcloud services enable artifactregistry.googleapis.com
7. Krok po kroku: przygotuj statyczny landing HTML
W Cloud Shell utwórz folder:
mkdir landing-demo
cd landing-demo
Utwórz plik index.html:
cat > index.html <<'EOF'
<!doctype html>
<html lang="pl">
<head>
<meta charset="utf-8">
<title>Landing Demo — Google Cloud Run</title>
<meta name="description" content="Przykładowy standalone landing page wdrożony na Google Cloud Run.">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="/style.css">
</head>
<body>
<main class="hero">
<div class="badge">Standalone Landing Page</div>
<h1>Landing uruchomiony na Google Cloud Run</h1>
<p>
To prosta strona HTML/CSS/JS wdrożona jako kontener Nginx.
Kod może wygenerować ChatGPT, Claude albo Gemini.
</p>
<a class="btn" href="mailto:kontakt@example.com">Szybki kontakt</a>
</main>
<script src="/script.js"></script>
</body>
</html>
EOF
Utwórz style.css:
cat > style.css <<'EOF'
* {
box-sizing: border-box;
}
body {
margin: 0;
font-family: Arial, sans-serif;
background: #0f172a;
color: #ffffff;
}
.hero {
min-height: 100vh;
display: grid;
place-content: center;
padding: 40px;
text-align: center;
}
.badge {
display: inline-block;
margin: 0 auto 20px;
padding: 8px 14px;
border: 1px solid rgba(255,255,255,.3);
border-radius: 999px;
font-size: 14px;
}
h1 {
max-width: 900px;
font-size: clamp(36px, 7vw, 80px);
line-height: 1.05;
margin: 0 auto 24px;
}
p {
max-width: 720px;
margin: 0 auto 32px;
font-size: 20px;
line-height: 1.6;
color: #cbd5e1;
}
.btn {
display: inline-block;
padding: 16px 26px;
border-radius: 12px;
background: #38bdf8;
color: #0f172a;
font-weight: 700;
text-decoration: none;
}
EOF
Utwórz script.js:
cat > script.js <<'EOF'
console.log("Landing działa na Google Cloud Run.");
EOF
8. Krok po kroku: dodaj Nginx i Dockerfile
Utwórz nginx.conf:
cat > nginx.conf <<'EOF'
events {}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
server {
listen 8080;
server_name _;
root /usr/share/nginx/html;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|ico)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000";
try_files $uri =404;
}
}
}
EOF
Utwórz Dockerfile:
cat > Dockerfile <<'EOF'
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/
COPY style.css /usr/share/nginx/html/
COPY script.js /usr/share/nginx/html/
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 8080
CMD ["nginx", "-g", "daemon off;"]
EOF
9. Krok po kroku: deploy do Cloud Run
Najprostsza komenda:
gcloud run deploy landing-demo \
--source . \
--region europe-west1 \
--allow-unauthenticated
Co oznacza:
landing-demo— nazwa usługi Cloud Run,--source .— buduj z bieżącego folderu,--region europe-west1— region Belgia, dobry wybór dla Polski,--allow-unauthenticated— strona publiczna.
Po chwili dostaniesz adres:
https://landing-demo-xxxxx-ew.a.run.app
Wejdź w ten adres i sprawdź stronę.
Cloud Run obsługuje wdrożenie kodu przez gcloud run deploy, a Google opisuje również możliwość automatycznego budowania kontenera z kodu źródłowego.
10. Gotowy plik deploy.sh
Dla wygody utwórz deploy.sh:
cat > deploy.sh <<'EOF'
#!/bin/bash
set -e
SERVICE_NAME="landing-demo"
REGION="europe-west1"
gcloud run deploy "$SERVICE_NAME" \
--source . \
--region "$REGION" \
--allow-unauthenticated
echo "Deploy zakończony."
EOF
chmod +x deploy.sh
Następny deploy robisz już tylko:
./deploy.sh
11. Jak pracować z kodem pisanym przez ChatGPT / Claude / Gemini?
Najlepszy workflow:
1. AI generuje kod.
2. Wklejasz kod do Cloud Shell Editor.
3. Testujesz strukturę plików.
4. Deployujesz na Cloud Run.
5. Sprawdzasz adres *.run.app.
6. Poprawiasz z AI błędy.
7. Podpinasz domenę.
Prompt do AI przy generowaniu landing page
Napisz standalone landing page w HTML/CSS/JS.
Wymagania:
- jeden folder projektu,
- pliki: index.html, style.css, script.js, Dockerfile, nginx.conf, deploy.sh,
- deployment na Google Cloud Run,
- Nginx ma słuchać na porcie 8080,
- strona ma być responsywna,
- bez zewnętrznych frameworków,
- meta title, meta description, Open Graph,
- sekcja hero, oferta, korzyści, FAQ, CTA, kontakt,
- kod gotowy do wklejenia w Cloud Shell Editor.
Prompt do poprawy błędu
Mam błąd podczas deploya na Google Cloud Run.
Oto log:
[wklej log]
Oto struktura plików:
[wklej ls -la]
Oto Dockerfile:
[wklej Dockerfile]
Znajdź przyczynę i napisz dokładnie, co mam zmienić.
12. Krok po kroku: mapowanie domeny do Cloud Run
Po deployu masz adres techniczny:
https://landing-demo-xxxxx.run.app
Teraz chcesz np.:
https://yyyyyyyyyyyy.pl
albo:
https://www.yyyyyyyyyyy.pl
Krok 1: przejdź do Cloud Run
W Google Cloud Console:
Cloud Run → wybierz usługę → Manage custom domains
Albo:
Cloud Run → Domain mappings
Google opisuje oficjalny proces: w Domain mappings kliknij Add Mapping, wybierz usługę, wybierz Cloud Run Domain Mappings, a następnie zweryfikuj domenę.
Krok 2: zweryfikuj domenę
Google może poprosić o potwierdzenie, że domena należy do Ciebie. Zwykle robisz to przez rekord TXT w DNS.
Jeżeli masz domenę w OVH:
OVH → Domeny → twojadomena.pl → Strefa DNS → Dodaj rekord TXT
Wklejasz rekord pokazany przez Google.
Krok 3: dodaj DNS-y mapowania
Po weryfikacji Google pokaże rekordy DNS, które trzeba dodać u rejestratora.
Dla domeny głównej zwykle będą rekordy A/AAAA.
Dla subdomeny, np. www, często CNAME.
W OVH:
Domena → Strefa DNS → Dodaj rekord
Wklej dokładnie rekordy z Google.
Krok 4: poczekaj na propagację DNS
Zwykle:
kilka minut do kilku godzin
Czasem do 24–48h, zależnie od DNS.
Ważne ograniczenia Cloud Run Domain Mapping
Google wskazuje kilka ograniczeń: przy Cloud Run domain mappings mapujesz domenę do /, nie do konkretnej ścieżki URL typu /users; nie możesz używać wildcard certificates; są też ograniczenia regionalne i długości mapowania.
Praktycznie:
Dobrze:
cobots.pl → usługa Cloud Run
www.cobots.pl → usługa Cloud Run
lab.geoknows.pl → usługa Cloud Run
Nie tak:
cobots.pl/kampania → osobna usługa przez domain mapping
Jeżeli chcesz routing po ścieżkach, wiele subdomen, zaawansowane SSL lub CDN, lepiej użyć Load Balancera albo Firebase Hosting jako warstwy przed Cloud Run.
13. Model pracy z domenami dla wielu landingów
Dla wielu landingów najlepiej używać subdomen:
cobots.pl
demo.cobots.pl
ai.geoknows.pl
lab.geoknows.pl
searchbox.geoknows.pl
rent.packrent.pl
parts.packfix.pl
Prosty model
1 landing = 1 Cloud Run service = 1 subdomena
Przykład:
Cloud Run service: cobots-landing
Domena: cobots.pl
Cloud Run service: searchbox-geo-lab
Domena: searchbox.geoknows.pl
Cloud Run service: packrent-rfq
Domena: rfq.packrent.pl
To jest najczytelniejsze dla początkującego.
14. Koszty: jak nie zrobić sobie przypadkowo dużego rachunku?
14.1. Ustaw budżet od razu
W Google Cloud:
Billing → Budgets & alerts → Create budget
Proponowane alerty:
50%, 80%, 100%
Budżety nie zawsze automatycznie blokują usługi, ale ostrzegają, że koszty rosną. Google opisuje budżety jako mechanizm śledzenia wydatków i wysyłania alertów przy progach budżetowych.
14.2. Cloud Run zwykle jest tani dla małych landingów
Google na stronie Cloud Run podaje, że usługa oferuje 2 miliony requestów miesięcznie bez opłat.
Ale uwaga: realne koszty mogą obejmować także:
- Cloud Build,
- Artifact Registry,
- ruch wychodzący,
- logi,
- Load Balancer, jeśli użyjesz,
- Cloud SQL, jeśli dodasz bazę,
- Vertex AI / Agent Platform, jeśli użyjesz AI,
- inne API.
Dlatego budżet i alerty są obowiązkowe.
14.3. Unikaj drogich usług na start
Na początku nie włączaj bez potrzeby:
- dużych baz danych,
- GPU,
- Vertex AI endpoints,
- Kubernetes,
- Load Balancerów,
- wielu środowisk,
- logów o bardzo dużej objętości.
Dla prostego landing page wystarczy:
Cloud Run + Cloud Build + Artifact Registry + Domain Mapping
15. Bezpieczeństwo: minimum dla początkującego
15.1. Nie dawaj wszystkim roli Owner
Google zaleca zasadę least privilege. Role podstawowe, takie jak Owner/Editor, zawierają bardzo wiele uprawnień, więc w produkcji należy dawać najbardziej ograniczone role, które wystarczają do zadania.
Praktycznie:
Ty / właściciel: Owner
Programista: Cloud Run Developer + Cloud Build Editor, jeśli potrzebne
Osoba od treści: brak dostępu do Google Cloud, jeśli nie musi
Księgowość: Billing Viewer
15.2. Nie wklejaj sekretów do kodu
Nie trzymaj w index.html, script.js ani Dockerfile:
- haseł,
- kluczy API,
- tokenów,
- danych do bazy,
- prywatnych webhooków.
Jeżeli kiedyś dodasz API, używaj:
Secret Manager
environment variables
service accounts
15.3. Publiczna strona? Użyj --allow-unauthenticated
Dla landingów publicznych to normalne.
Dla paneli wewnętrznych albo narzędzi prywatnych nie używaj publicznego dostępu.
16. Co to jest Agent Platform w Google Cloud?
Link, który podałeś:
console.cloud.google.com/agent-platform/overview
prowadzi do środowiska Google Cloud dla agentów AI. Obecnie Google opisuje Gemini Enterprise Agent Platform jako zunifikowaną platformę do budowania, wdrażania, zarządzania i optymalizacji agentów klasy enterprise. Platforma obejmuje cały cykl AI: od dostępu do ponad 200 modeli foundation, przez budowę agentów, aż po governance i optymalizację.
Google opisuje tam m.in.:
- Agent Development Kit — framework do budowy agentów,
- Agent Studio — low-code canvas do projektowania agentów,
- Agent Garden — gotowe szablony agentów,
- Model Garden — dostęp do modeli Google, third-party i open-source,
- RAG Engine — podłączanie danych firmowych do LLM,
- Vector Search — wyszukiwarka wektorowa dla AI,
- Managed Agents API — agenci w zarządzanym sandboxie,
- Agent Runtime — skalowanie agentów,
- Memory Bank — pamięć agentów,
- Code Execution — wykonywanie kodu przez agentów w bezpiecznym środowisku.
Dla początkującego: czy zaczynać od Agent Platform?
Nie. Najpierw opanuj:
Cloud Shell → Cloud Run → domena → deploy landing page
Dopiero potem:
Agent Platform → Agent Studio / ADK → RAG → agenci firmowi
Agent Platform ma sens, gdy chcesz budować np.:
- chatbota firmowego,
- agenta obsługi klienta,
- agenta analizującego dokumenty,
- agenta SEO/GEO,
- agenta do raportów,
- agenta sprzedażowego,
- agenta do workflow B2B,
- narzędzie AI podłączone do danych firmy.
17. Praktyczne zastosowania Google Cloud dla Waszych projektów
17.1. Standalone landing pages
Najlepszy start:
Cloud Run + HTML/CSS/JS + domain mapping
Przykłady:
- cobots.pl,
- agentbox.pl,
- geoaudyt.pl,
- narzędzie GEO,
- strona kampanii Google Ads,
- landing produktu.
17.2. Mini-narzędzia SEO/GEO
Przykłady:
- SearchBox GEO Lab,
- Query Fan-Out Generator,
- AI Citation Planner,
- FAQ Generator,
- Schema Checklist,
- Agent-Ready Form Checker.
Początkowo mogą działać w 100% po stronie przeglądarki, bez API.
Później można dodać backend:
Cloud Run + Node.js/Python + API Gemini/OpenAI/Anthropic
17.3. Formularze RFQ / lead generation
Możesz mieć prosty landing:
formularz → webhook → e-mail → CRM / Google Sheets
Wariant prosty:
Formularz HTML + zewnętrzny backend typu Formspree / Make / Apps Script
Wariant własny:
Cloud Run backend + SendGrid / Gmail API / Sheets API
17.4. Agent-ready B2B pages
Cloud Run pozwala szybko tworzyć strony, które są przyjazne dla agentów AI:
- proste formularze,
- jasne CTA,
- dane produktowe,
- FAQ,
- JSON-LD,
- pliki PDF,
- mikro-narzędzia.
17.5. Agent Platform / AI workflows
Późniejszy etap:
- agent do analizy zapytań klientów,
- agent do generowania ofert,
- agent SEO/GEO,
- agent do monitoringu trendów,
- agent do obsługi dokumentów,
- agent połączony z Google Workspace.
18. Rekomendowany workflow dla Was: od pomysłu do domeny
Etap 1: Pomysł
Przykład:
Chcemy landing cobots.pl dla rozwiązań cobotycznych UR / DI-ZET.
Etap 2: Prompt do AI
Napisz standalone landing page HTML/CSS/JS dla cobots.pl.
Ma mieć:
- hero,
- problem klienta,
- rozwiązania,
- zastosowania,
- FAQ,
- CTA,
- schema.org,
- meta SEO,
- Open Graph,
- Dockerfile,
- nginx.conf,
- deploy.sh pod Cloud Run.
Etap 3: Wklejenie kodu do Cloud Shell Editor
Wchodzisz do Cloud Shell Editor, tworzysz pliki.
Etap 4: Deploy
./deploy.sh
Etap 5: Test pod adresem run.app
Sprawdzasz:
- wygląd,
- mobile,
- przyciski,
- linki,
- meta,
- szybkość,
- błędy w konsoli.
Etap 6: Mapowanie domeny
Podpinasz:
cobots.pl → Cloud Run service
Etap 7: DNS w OVH
Dodajesz rekordy pokazane przez Google.
Etap 8: Search Console
Dodajesz domenę do Google Search Console.
Etap 9: Analytics
Dodajesz GA4 / Tag Manager.
Etap 10: Iteracja
Co tydzień:
- poprawiasz treść,
- dodajesz FAQ,
- dodajesz sekcje,
- testujesz konwersję,
- dodajesz formularz,
- sprawdzasz GSC.
19. Checklista przed publikacją landing page
Techniczna
- Strona działa pod
run.app. - Domena działa.
- HTTPS działa.
- Mobile działa.
- Linki działają.
- Nie ma błędów JS.
- Formularz działa.
- Strona ma
titleimeta description. - Jest Open Graph.
- Jest favicon.
- Jest robots / indexacja zgodna z celem.
SEO / GEO / AEO
- H1 jest jasny.
- Jest Short Answer.
- Są nagłówki H2.
- Jest FAQ.
- Jest CTA.
- Są dane kontaktowe.
- Jest schema.org.
- Jest sekcja „dla kogo”.
- Jest sekcja „kiedy warto”.
- Jest sekcja „jak działa”.
- Jest data aktualizacji lub jasny kontekst.
Biznesowa
- Użytkownik wie, co oferujemy.
- Użytkownik wie, dla kogo jest oferta.
- Użytkownik wie, co zrobić dalej.
- Nie ma zbędnych pól w formularzu.
- Kontakt jest widoczny.
- CTA jest na górze i na dole.
- Strona odpowiada na najważniejsze pytania klienta.
20. Najczęstsze błędy początkujących
Błąd 1: brak budżetu
Pierwsza rzecz po utworzeniu projektu: Billing → Budgets & alerts.
Błąd 2: wszystkie projekty w jednym koszyku
Nie mieszaj landingów testowych, klientów, agentów i produkcji w jednym projekcie.
Błąd 3: nieczytelne nazwy usług
Źle:
test1
new-service
landing-final-final
Dobrze:
cobots-landing-prod
geoknows-searchbox-lab
packrent-rfq-prod
Błąd 4: brak nginx.conf na port 8080
Cloud Run oczekuje, że aplikacja będzie nasłuchiwała na odpowiednim porcie. W naszym modelu Nginx słucha na 8080.
Błąd 5: mapowanie domeny przed testem run.app
Najpierw upewnij się, że strona działa pod adresem Cloud Run. Dopiero potem mapuj domenę.
Błąd 6: zbyt ciężki landing
Nie wrzucaj dużych bibliotek, filmów i obrazów bez optymalizacji. Standalone landing ma być szybki.
Błąd 7: kopiowanie kodu z AI bez sprawdzenia
AI może wygenerować błędny Dockerfile, niedziałający JS albo zbyt skomplikowaną strukturę. Testuj małymi krokami.
21. Minimalny słownik Google Cloud dla laika
| Pojęcie | Proste znaczenie |
|---|---|
| Project | Oddzielny kontener na usługi i billing |
| Billing | Rozliczenia i płatności |
| Budget | Alert kosztów |
| Cloud Shell | Terminal w przeglądarce |
| Cloud Shell Editor | Edytor kodu w przeglądarce |
| gcloud | Komendy do Google Cloud |
| Cloud Run | Uruchamianie aplikacji / strony z kontenera |
| Container | Paczka z aplikacją i środowiskiem |
| Dockerfile | Instrukcja budowy kontenera |
| Nginx | Serwer do podania statycznej strony |
| Domain Mapping | Podpięcie domeny do usługi |
| DNS | Rekordy domeny u rejestratora |
| IAM | Uprawnienia |
| Artifact Registry | Magazyn obrazów kontenerów |
| Cloud Build | Budowanie kontenera z kodu |
| Agent Platform | Platforma do budowy agentów AI |
22. Najlepsza ścieżka nauki na 7 dni
Dzień 1: Console i Project
- załóż projekt,
- podepnij billing,
- ustaw budget alert,
- uruchom Cloud Shell.
Dzień 2: Cloud Shell Editor
- otwórz edytor,
- utwórz folder,
- utwórz
index.html, - naucz się zapisywać pliki.
Dzień 3: Pierwszy deploy Cloud Run
- utwórz
Dockerfile, - utwórz
nginx.conf, - wykonaj
gcloud run deploy, - sprawdź adres
run.app.
Dzień 4: Poprawki i redeploy
- zmień tekst,
- zmień kolor,
- dodaj FAQ,
- wykonaj ponownie
./deploy.sh.
Dzień 5: Domain Mapping
- zweryfikuj domenę,
- dodaj rekordy DNS,
- poczekaj na propagację.
Dzień 6: SEO / Analytics
- dodaj meta title,
- dodaj meta description,
- dodaj Open Graph,
- dodaj GA4,
- dodaj Search Console.
Dzień 7: Proces z AI
- poproś ChatGPT / Claude o poprawę kodu,
- poproś o audyt UX,
- poproś o schema,
- poproś o wersję mobile,
- wdroż poprawki.
23. Model docelowy dla Waszych landing pages
Dla każdego nowego standalone projektu warto mieć standard:
/project-name
├── index.html
├── style.css
├── script.js
├── assets/
│ ├── logo.svg
│ ├── hero.webp
│ └── og-image.webp
├── nginx.conf
├── Dockerfile
├── deploy.sh
├── README.md
└── prompts.md
README.md
Zawiera:
Nazwa projektu
Domena
Cloud Run service
Region
Project ID
Data deploya
Instrukcja deploya
Kontakt techniczny
prompts.md
Zawiera prompty użyte do wygenerowania kodu:
Prompt do stworzenia strony
Prompt do poprawy CSS
Prompt do schema
Prompt do meta SEO
Prompt do deploy.sh
To bardzo ułatwia pracę, gdy po kilku miesiącach wracasz do projektu.
24. Podsumowanie
Google Cloud może wyglądać skomplikowanie, ale do Twojego zastosowania wystarczy bardzo prosta ścieżka:
Google Cloud Console
→ Project
→ Billing + Budget
→ Cloud Shell
→ Cloud Shell Editor
→ HTML/CSS/JS
→ Dockerfile + Nginx
→ Cloud Run deploy
→ Domain Mapping
→ DNS w OVH
→ Search Console / GA4
Najważniejsza zasada:
Nie ucz się całego Google Cloud naraz. Naucz się jednego powtarzalnego procesu: jak z folderu z kodem zrobić działającą stronę pod własną domeną.
Dopiero potem rozwijaj:
- formularze,
- backend,
- bazy danych,
- mini-narzędzia,
- API,
- Agent Platform,
- RAG,
- automatyzacje.
Dla GEO/AEO/AIO to jest bardzo mocny kierunek: możesz szybko budować mikronarzędzia, standalone landing pages i agent-ready strony bez ciężkiego WordPressa i bez długiego cyklu developerskiego.
Meta — Yoast SEO
Fraza kluczowa:
Google Cloud dla początkujących
Tytuł SEO:
Google Cloud dla początkujących — Cloud Run, Cloud Shell, domena i landing HTML krok po kroku
Link / slug:
google-cloud-dla-poczatkujacych-cloud-run-landing-html
Opis:
Praktyczny przewodnik Google Cloud dla początkujących: Cloud Shell, Cloud Run, standalone HTML landing pages, deploy, domena, DNS, koszty, Agent Platform i bezpieczeństwo.
Źródła
- Google Cloud — Cloud Run: opis usługi, strony i aplikacje, skalowanie do zera, 2 mln requestów miesięcznie bez opłat oraz deploy przez
gcloud run deploy. - Google Cloud Docs — Cloud Shell: gotowy terminal i edytor kodu w przeglądarce z Google Cloud CLI.
- Google Cloud Docs — uruchamianie Cloud Shell Editor z konsoli i przez
shell.cloud.google.com. - Google Cloud Docs — Cloud Run custom domain mapping: mapowanie domeny do usługi, weryfikacja domeny i ograniczenia.
- Google Cloud Docs — ograniczenia Cloud Run domain mappings, m.in. mapowanie tylko do
/, brak wildcard certificates i ograniczenia regionalne. - Google Skills — przykład statycznej strony na Cloud Run z Nginx,
Dockerfile, kopiowaniemindex.htmli portem 8080. - Google Cloud Billing Docs — budżety i alerty kosztów.
- Google Cloud IAM Docs — zasada least privilege i unikanie szerokich ról podstawowych w produkcji.
- Google Cloud — Gemini Enterprise Agent Platform: platforma do budowy, skalowania, governance i optymalizacji agentów.
- Google Cloud Docs — Agent Platform overview: ADK, Agent Studio, Agent Garden, Model Garden, RAG Engine, Vector Search, Managed Agents API, Agent Runtime, Memory Bank i Code Execution.
Napisz do nas jak chciałabyś/chciałbyś aby Twój produkt/usługa był prezentowany w naszym multiversum i by omówić szczegóły współpracy:
🌍 GEOknows.pl | SalesBot.pl | IntegratorAI.pl
