Wyjaśnienie
Oddziel fakt, interpretację i działanie. W tym krótkim ćwiczeniu stosuj trzy poziomy:
- P0 — blokada: ważna publiczna strona jest niedostępna, przypadkowo zablokowana przed skanowaniem/indeksowaniem albo powoduje krytyczny błąd widoczny dla użytkownika; najpierw potwierdź wpływ na dokładny adres URL.
- P1 — istotna niespójność: ważna strona ma ścieżkę odkrycia lub otwiera się, ale jej treść, język,
canonical/odnośniki lub formularz utrudniają zrozumienie albo korzystanie. Stwierdzenie „system wyszukiwania odkrył stronę” wymaga osobnego potwierdzenia w panelu lub zweryfikowanym logu. - P2 — usprawnienie: problem nie blokuje dostępu ani nie wprowadza użytkownika w błąd; zapisz go i zaplanuj po usunięciu blokad.
To robocza skala na potrzeby kursu, a nie standard wyszukiwarki. Przy podobnej pilności wyżej traktuj problem z mocniejszymi, odtwarzalnymi dowodami i większym wpływem na użytkowników.
Kryteria możliwe do sprawdzenia:
- Ścieżka odkrycia: zwykły odnośnik HTML ze sprawdzonej strony testowej albo adres w sprawdzonej mapie witryny. Zapisz źródło; wskazuje ono możliwą drogę znalezienia adresu, a nie potwierdza, że system go znalazł.
- Odkrycie przez system: potwierdź je w odpowiednim raporcie wyszukiwarki lub zweryfikowanych logach pobrań.
- Spójność adresu URL i canonical: odnośnik prowadzi do oczekiwanego adresu końcowego, odpowiedź jest prawidłowa,
canonicalodpowiada docelowej wersji, a mapa zawiera ten sam adres kanoniczny. Adres wybrany przez wyszukiwarkę sprawdź osobno w jej raporcie. - Żaden z tych testów samodzielnie nie potwierdza indeksowania.
Fikcyjny przykład
Testowa makieta szkoleniowa /robots ma następujące sygnały: odnośnik z katalogu prowadzi do adresu http://, który przekierowuje; canonical w HTML wskazuje /robots-v2, a mapa witryny zawiera /robots. To niespójność P1, jeśli obie strony są dostępne i użytkownik może dotrzeć do treści; wyższy priorytet uzasadnij dopiero dodatkowym dowodem blokady lub utraty dostępu. Zmiany canonical, robots/noindex i WAF mogą wpływać na dostęp oraz sygnały witryny, dlatego każda prawdziwa zmiana wymaga zgody właściciela, wcześniejszej oceny i sprawdzonego planu wycofania.
Ćwiczenie
Pracuj wyłącznie w środowisku testowym lub lokalnej kopii example.test:
- Dodaj sprzeczny stan odnośnika,
canonicali mapy witryny dla/robotsw makiecie testowej. - Uzupełnij wiersz dziennika surowymi dowodami i ograniczeniami wniosku.
- Przypisz P0/P1/P2 zgodnie z powyższymi kryteriami.
- Zaproponuj poprawkę i oczekiwaną, możliwą do zaobserwowania zmianę, ale nie wdrażaj jej w produkcji.
- Sprawdź poprawkę w środowisku testowym tymi samymi metodami. Każda prawdziwa zmiana produkcyjna w
robots.txt,noindex,canonicallub WAF wymaga najpierw potwierdzonego właściciela, pisemnej oceny wpływu i planu wycofania; wdrożenie przebiega zwykłym procesem wydawniczym. Nie zmieniaj produkcji na potrzeby tego ćwiczenia.
Lista kontrolna
- Zapisano adres URL, czas, narzędzie i surowe dowody.
- Ścieżka odkrycia (odnośnik/mapa) jest oddzielona od potwierdzonego odkrycia przez system (panel/zweryfikowany log).
- Osobno sprawdzono URL, przekierowanie,
canonicali mapę witryny. - Priorytet wyjaśniono wpływem i wiarygodnością obserwacji.
- Ćwiczenie i poprawkę wykonano wyłącznie w środowisku testowym/example.test.
- Każda przyszła zmiana produkcyjna wskazuje właściciela, przegląd i plan wycofania.
- Kontrola przed i po używa tego samego URL, narzędzia i warunków.
Częsty błąd
Zmiana produkcyjnego robots.txt, canonical lub WAF „na próbę” i sprawdzanie dopiero po wdrożeniu. Taka zmiana może zablokować przydatną sekcję lub zmienić dostęp. Zacznij od środowiska testowego, właściciela, przeglądu i planu wycofania.
Zestaw powtarzalnych pytań i punkt odniesienia dla migracji
Do powtarzalnych kontroli odpowiedzi AI przechowuj niewielki, stabilny zestaw prawdziwych pytań klientów. Zapisuj dokładne brzmienie, język, region, powierzchnię produktu, datę oraz warunki konta/sesji. Uwzględnij pytania odkrywcze, porównawcze i decyzyjne; nie dodawaj nazwy marki do każdego zapytania. Przykładowe pytanie dotyczące fikcyjnej witryny: „Co sprawdzić przed przeniesieniem małej witryny dokumentacyjnej do nowej domeny?”. Zapisuj pełną odpowiedź i cytowane adresy URL. To protokół pomiaru, a nie zalecana liczba zapytań ani obietnica cytowania.
Przed migracją wyeksportuj listę starych adresów URL i przygotuj osobny wiersz dla każdego ważnego adresu: stary adres, zamierzony cel, status przekierowania, końcowa odpowiedź, adres canonical, odnośniki wewnętrzne oraz obecność w mapie witryny. Przetestuj mapowanie w środowisku testowym, uwzględniając parametry zapytania i warianty ukośnika końcowego używane przez witrynę. Przed uruchomieniem porównaj reprezentatywną próbkę, a po uruchomieniu ponownie sprawdź te same adresy. Nie zastępuj mapy przekierowań bezwarunkowym przekierowaniem na stronę główną; nie zmieniaj produkcji bez zatwierdzonego przez właściciela wdrożenia i planu wycofania.
W tym ćwiczeniu kolumna „Wynik po uruchomieniu” jest wyłącznie przyszłym punktem odniesienia: wpisz „nie dotyczy — brak wdrożenia produkcyjnego”. Uzupełnij ją dopiero po wdrożeniu zatwierdzonym przez właściciela.
| Stary adres URL | Zamierzony cel | Wynik w środowisku testowym | Wynik po uruchomieniu |
|---|---|---|---|
https://example.test/guide-a | https://example.test/docs/guide-a | zapisz status i końcowy adres | powtórz to samo żądanie |
https://example.test/guide-b | https://example.test/docs/guide-b | zapisz status i końcowy adres | powtórz to samo żądanie |
Host .test i wszystkie powyższe wiersze to fikcyjne przykłady.