Technický baseline audit

Fáze P2 · Etapa A — Pochopte
Časový rámec: 2–4 hodiny pro lehký průchod, 1–2 pracovní dny pro standardní průchod nebo 3–8 pracovních dnů pro hloubkový průchod.
Vlastník: technický SEO lead. Inženýři, analytici, obsahová a lokalizační oddělení přispívají důkazy a schvalují opravy ve svých oblastech.

Technický baseline audit zjišťuje, zda vyhledávače mohou dosáhnout, interpretovat a vybrat URL, které by podle očekávání podniku měly zobrazovat. Jeho rozsah zahrnuje řízení procházení, HTTP odpovědi, indexaci, kanonické URL, odkazy, rendering, mezinárodní cílení a bezpečné doručování. Výsledkem je prioritizovaný registr nálezů s určenými vlastníky a akceptačními testy, nikoli skóre.

Proč tato fáze přichází sem

Publikování na webu s problémy s procházením nebo indexací znásobuje škody. Vyhledávače často objeví opakovaný defekt napříč novými URL rychleji, než vyhodnotí a odmění obsah. Rozbitá šablona kanonických URL může každý článek směřovat jinam; pravidlo robots.txt může skrýt adresář; navigace renderovaná na straně klienta může vytvořit sirotky pro klienta bez JavaScriptu. Každá nová stránka rozšiřuje zasaženou množinu a činí opravu riskantnější.

Nejprve opravte základy. Pořadí je procházení → indexovatelnost → kvalita obsahu → výkon, protože každá vrstva je bránou. Procházení znamená, že crawler může objevit a požádat o URL; indexovatelnost znamená, že dosažitelná URL je způsobilá k zařazení. Teprve poté lze posuzovat kvalitu obsahu a výkon. Rychlá stránka blokovaná robots.txt nemůže konkurovat a title tagy na nedosažitelných stránkách nehrají roli.

Tato fáze spotřebovává rozsah, prioritní cesty, trhy a rizika z fáze Objevování a cíle . Pokud se provede dříve, vznikne procházení bez obchodního kontextu. Pokud se přeskočí, výzkum a produkce cílí na šablony, které se nemohou spolehlivě dostat do indexu.

Vstupy a výstupy

Vstupy definují zamýšlený web, nejen to, co crawler najde. Výstupy sdělují dalšímu vlastníkovi, které URL jsou bezpečné k testování a které zůstávají blokované.

Zvolte hloubku auditu

Hloubku zvolte před procházením. Odhady předpokládají připravený přístup a nezahrnují implementaci.

Kontrolní seznam

Pracujte v pořadí. Selhání brány může zneplatnit pozdější vzorky, proto před pokračováním zaznamenejte selhání a jeho rozsah.

1. Potvrďte, že cíl je produkce

Co dělat: ověřte schéma, hostitele, robots soubor, analytickou vlastnost, vlastnost Search Console a hostitele sitemap. Proč to má význam: staging může vypadat čistě, zatímco produkce zůstává rozbitá. Jak to udělat: vyřešte dohodnutého kanonického hostitele, porovnejte prioritní stránky a hlavičky odpovědí a zaznamenejte zdroj procházení. Nástroj: prohlížeč, konfigurace crawleru, výběr Search Console. Hotovo, když: registr uvádí potvrzený produkční zdroj a vlastnost, bez hostitele stagingu v semenech nebo exportech.

2. Otestujte robots.txt před procházením

Co dělat: zkontrolujte /robots.txt každého produkčního hostitele a odkazované sitemapy. Proč to má význam: pravidlo Disallow brání procházení dříve, než může být obsah vyhodnocen. Jak to udělat: porovnejte vzory Disallow se zamýšleným inventářem, otestujte odpovídající i neodpovídající URL a rozlište blokování procházení od noindex. Nástroj: surová odpověď a tester robots. Hotovo, když: robots vrací 200, zamýšlené blokace mají důvody, indexovatelné vzorky jsou povoleny a jeden nezamýšlený blok spouští kritický nález.

3. Porovnejte sitemapy se skutečnými URL

Co dělat: porovnejte odeslané sitemapy s kanonickým indexovatelným inventářem. Proč to má význam: sitemapa by měla uvádět URL, které chce web vybrat, nikoli přesměrování, chyby nebo duplicity. Jak to udělat: normalizujte položky, porovnejte počty podle šablon, poté vzorkujte přidané a chybějící položky v Sitemapy a indexace . Nástroj: https://app.amicited.com/reports/google-search/sitemaps-indexing a exporty z procházení. Hotovo, když: pokrytí je alespoň 95 %, 0 položek přesměrovává nebo chybuje a každá mezera má důvod nebo vlastníka.

4. Změřte rozdělení stavových kódů

Co dělat: klasifikujte odpovědi jako 2xx, 3xx, 4xx nebo 5xx. Proč to má význam: chyby zastavují získávání a přesměrování přidávají skoky. Jak to udělat: sledujte a hlaste přesměrování, segmentujte podle šablon a porovnejte s Procházení Bingem . Nástroj: https://app.amicited.com/reports/bing-webmasters/crawl, crawler a monitoring. Hotovo, když: indexovatelné URL vracejí 200; interní chyby, smyčky a řetězce jsou nulové; a záměrná přesměrování jsou zdokumentována.

5. Odstraňte řetězce přesměrování a smyčky

Co dělat: sledujte přesměrování až ke konečné odpovědi. Proč to má význam: skoky zpomalují objevování; smyčka se nikdy nedostane k obsahu. Jak to udělat: exportujte cesty, aktualizujte interní odkazy na finální kanonické URL a konsolidujte pravidla. Nástroj: report přesměrování a kontroly hlaviček. Hotovo, když: interní odkazy jdou přímo, legacy přesměrování mají jeden skok a neexistuje žádná smyčka ani řetězec.

6. Stanovte způsobilý poměr indexace

Co dělat: porovnejte stav indexu Google s záměrně způsobilými URL. Proč to má význam: zahrnutí přesměrování, filtrů, duplicit nebo stránek s noindex činí poměr bezvýznamným. Jak to udělat: sestavte způsobilý jmenovatel, zkontrolujte prioritní vzorky v Kontrola URL a seskupte výjimky podle šablon. Nástroj: https://app.amicited.com/reports/google-search/url-inspection, Search Console a inventář. Hotovo, když: je indexováno alespoň 90 % nebo každá mezera má vlastníka s hlavní příčinou; pod 80 % je závažný nález.

7. Ověřte správnost kanonických URL

Co dělat: porovnejte deklarované, finální a Googlem vybrané kanonické URL. Kanonická URL je preferovaná verze mezi podobnými URL. Proč to má význam: špatná kanonická URL konsoliduje signály pryč od zamýšlené stránky. Jak to udělat: otestujte sebereference unikátních stránek, záměrné křížové kanonické URL a konzistenci napříč HTML, sitemapami, přesměrováními a odkazy. Nástroj: report kanonických URL a https://app.amicited.com/reports/google-search/url-inspection. Hotovo, když: 100 % unikátních indexovatelných stránek uvádí jednu absolutní, 200, indexovatelnou kanonickou URL a každý vybraný nesoulad je vysvětlen.

8. Najděte shluky duplicit a téměř duplicit

Co dělat: seskupte URL s identickým nebo podstatně překrývajícím se hlavním obsahem a stejným vyhledávacím účelem. Proč to má význam: duplicity rozdělují interní signály a nutí vyhledávače vybrat verzi, kterou podnik nemusí preferovat. Jak to udělat: porovnejte přesné hashe, normalizovanou textovou podobnost, názvy, kanonické URL, parametry a účel šablony; poté zvolte konsolidaci, diferenciaci, noindex nebo odstranění. Nástroj: reporty duplicit z crawleru, inventář stránek a Stránky ve vyhledávání Google . Hotovo, když: žádný shluk neobsahuje více než jednu nevysvětlenou kanonickou indexovatelnou URL sloužící stejnému záměru a každá akceptovaná varianta má zaznamenaný odlišný účel.

9. Najděte sirotky a změřte hloubku odkazů

Co dělat: spojte URL z crawleru se sitemapami, analytikou, Search Console, CMS exporty a zpětnými odkazy a najděte stránky bez procházeného interního odkazu. Změřte nejkratší cestu kliknutím z domovské stránky. Proč to má význam: sirotek se může objevit v sitemapě, ale získává málo interního kontextu nebo autority; nadměrná hloubka činí objevování křehkým. Jak to udělat: porovnejte zdroje, prozkoumejte vzory adresářů v Zobrazení adresářů a sledujte navigaci, drobečkovou navigaci, rozcestníky a kontextové odkazy. Nástroj: https://app.amicited.com/reports/directory a vícerozdrojové procházení. Hotovo, když: zamýšlený počet sirotků je nulový, prioritní stránky jsou do tří kliknutí z domovské stránky, ostatní zamýšlené indexovatelné stránky jsou do pěti kliknutí a každá výjimka má záměrnou cestu objevení.

10. Porovnejte rendrované HTML a HTML bez JavaScriptu

Co dělat: porovnejte počáteční odpověď serveru se stránkou po provedení JavaScriptu. Proč to má význam: prohlížeč může zobrazit obsah a odkazy, které klient bez JavaScriptu nikdy neobdrží. Jak to udělat: načtěte reprezentativní stránky s vypnutými skripty, zkontrolujte surové HTML, poté porovnejte nadpisy, hlavní text, odkazy, kanonickou URL, robots direktivy, strukturovaná data a stav po rendrování. Nástroj: crawler v HTML a rendrovaném režimu plus vývojářské nástroje prohlížeče. Hotovo, když: počáteční odpověď obsahuje primární obsah, kanonickou URL, index direktivy a procházenou navigaci potřebnou k objevení prioritních stránek; jakákoli závislost pouze na JavaScriptu je explicitně akceptována a testována napříč šablonami.

11. Ověřte hreflang tam, kde je to relevantní

Co dělat: ověřte anotace, které propojují jazykové nebo regionální ekvivalenty. Proč to má význam: neúplné nebo konfliktní shluky mohou způsobit, že vyhledávače ignorují cílení a zobrazí nesprávnou tržní verzi. Jak to udělat: otestujte platné kódy jazyků a regionů, absolutní kanonické URL, sebereference, reciproční zpětné odkazy, x-default tam, kde má skutečnou záložní roli, a indexovatelnost každého cíle. Nástroj: hreflang report crawleru a vzorky URL. Hotovo, když: neplatné kódy, chybějící sebereference, chybějící zpětné odkazy, nekanonické cíle, přesměrování a chyby jsou všechny nulové. Pokud web nemá žádné lokalizované ekvivalenty, zaznamenejte „nerelevantní“ namísto vymýšlení anotací.

12. Otestujte stránkování a cesty procházení

Co dělat: ověřte, že sekvence více stránek kategorie nebo archivu vystavují procházené odkazy a užitečné unikátní URL. Proč to má význam: nekonečný scroll nebo načítání pouze tlačítkem může skrýt hlubší položky, zatímco kanonikalizace každé stránky na první stránku může odstranit odlišný inventář z objevování. Jak to udělat: vypněte JavaScript, sledujte odkazy „další“ a číslované odkazy, zkontrolujte stav, kanonickou URL a robots direktivy a otestujte poslední stránku a parametry mimo rozsah. Nástroj: nerendrované procházení a prohlížeč. Hotovo, když: každá zamýšlená položka je dosažitelná přes kotvící odkazy, každá užitečná stránka se sama kanonikalizuje, neplatná čísla stránek vracejí odpovídající chybu spíše než měkké 200 a žádná sekvence nevytváří neomezený URL prostor.

13. Zkontrolujte mobilní paritu

Co dělat: porovnejte mobilní a desktopové doručování z hlediska obsahu, odkazů, metadat, direktiv, strukturovaných dat a stavu odpovědi. Proč to má význam: Google primárně vyhodnocuje mobilní reprezentaci; skrývání smysluplného obsahu nebo odkazů pouze na mobilu mění to, co může pochopit. Jak to udělat: procházejte s desktopovým a smartphone user agentem a porovnejte reprezentativní šablony, nejen vizuální screenshoty. Nástroj: párová procházení, mobilní kontrola URL a responzivní režim prohlížeče. Hotovo, když: všechen indexovatelný obsah a procházené odkazy potřebné pro význam a objevování jsou ekvivalentní s nulovými mobilními blokacemi, rozdíly v kanonických URL nebo chybovými odpověďmi.

14. Zaveďte HTTPS a odstraňte smíšený obsah

Co dělat: ověřte bezpečné doručování, přesměrování hostitelů, certifikáty, kanonické schéma, interní URL a zdroje načítané přes HTTP. Smíšený obsah znamená, že HTTPS stránka načítá nezabezpečený zdroj. Proč to má význam: nezabezpečené požadavky mohou být blokovány, vystavují uživatele riziku a vytvářejí nekonzistentní URL signály. Jak to udělat: procházejte všechny HTTP varianty, zkontrolujte pokrytí certifikátů a bezpečnostní chyby prohlížeče a prohledávejte požadavky na rendrované zdroje. Nástroj: crawler, bezpečnostní panel prohlížeče a konfigurace serveru. Hotovo, když: každá HTTP stránka přesměrovává jedním skokem na odpovídající HTTPS URL, všechny kanonické URL a interní odkazy používají HTTPS, certifikáty jsou platné pro každého živého hostitele a aktivní nebo pasivní požadavky na smíšený obsah jsou nulové.

Nástroje v AmICited

Používejte produktové reporty jako důkazy do kontrolního seznamu, nikoli jako náhradu procházení.

• Sitemapy a indexace na https://app.amicited.com/reports/google-search/sitemaps-indexing zobrazuje stav odeslaných sitemap, varování, chyby a akce indexace.
• Kontrola URL na https://app.amicited.com/reports/google-search/url-inspection poskytuje živé verdikty Google pro vzorkované URL a vybranou kanonickou URL.
• Procházení Bingem na https://app.amicited.com/reports/bing-webmasters/crawl odhaluje aktivitu Bing crawleru a problémy na úrovni URL.
• Stránky ve vyhledávání Google na https://app.amicited.com/reports/pages pomáhá vybrat vysoce hodnotné vstupní stránky a odděluje stránky s viditelností od stránek chybějících ve vyhledávacích datech.
• Zobrazení adresářů na https://app.amicited.com/reports/directory odhaluje vzory na úrovni sekcí a podporuje vyšetřování hloubky a sirotků.
• Zdraví dat na https://app.amicited.com/features/data-health/ zaznamenává, zda jsou připojené důkazy dostatečně úplné pro podporu důvěryhodných rozhodnutí.

Rozhodovací pravidla

Prahové hodnoty vytvářejí nálezy; nenahrazují úsudek. Segmentujte podle šablon a obchodní důležitosti: deset selhání v kategorii pokladny může mít větší význam než tisíc rozbitých archivačních tagů.

Prioritizujte pomocí dopad × úsilí × jistota. Ohodnoťte dopad 1–5 podle počtu zasažených způsobilých URL a obchodních cest. Ohodnoťte úsilí 1–5 jako faktor snadnosti, kde 5 znamená malou, vratnou změnu a 1 znamená velký riskantní program; také zaznamenejte skutečný odhad v hodinách nebo dnech. Ohodnoťte jistotu jako 0,5 pro pravděpodobnou hypotézu, 0,75 pro opakované důkazy nebo 1,0 pro reprodukovanou hlavní příčinu. Součin poskytuje pomůcku pro řazení, nikoli falešnou přesnost.

Aplikujte override závislostí: oprava, která odblokuje jinou práci, má přednost před vyšším skóre, které ji neodblokuje. Odstranění bloku robots.txt před spuštěním má přednost před vylepšováním indexovaných title tagů. Na stejné úrovni závislostí řešte nejprve příčiny v celé šabloně před příznaky.

Výstup: prioritizovaný registr nálezů

Předávejte jeden sdílený registr, nikoli export z crawleru. Použijte jeden řádek na hlavní příčinu a vzorky URL připojte samostatně.

Registr je kompletní, když kritické a závažné nálezy mají vlastníky a odhady, blokátory mají posloupnost, hypotézy jsou označeny a rozhodnutí o publikování je explicitní.

Co se pokazí

Report s 200 položkami, se kterými nikdo nemůže pracovat

Exporty z crawlerů zaměňují pozorování za rozhodnutí. Seskupte opakované URL pod šablonu nebo pravidlo, které je způsobuje, poskytněte reprezentativní vzorek a přiřaďte jednoho vlastníka. Dvě stě rozbitých URL vytvořených jednou navigační komponentou je jeden nález s hlavní příčinou s měřitelným rozsahem, nikoli dvě stě úkolů.

Hlášení příznaků místo příčin

„Stránka není indexována“ je příznak. Příčinou může být nezamýšlená kanonická URL, osiřelá šablona, varianty s tenkými parametry, mobilní chyba nebo odkaz pouze v JavaScriptu. Nález není připraven k prioritizaci, dokud neidentifikuje ovlivnitelnou příčinu nebo jasně neoznačí další diagnostický test.

Náhodný audit stagingu

Staging může mít jiná robots pravidla, autentizaci, data, šablony, feature flagy a chování hostitele. Zaznamenejte produkční zdroj a vlastnost Search Console na začátku každého exportu. Pokud musí procházení běžet proti stagingu kvůli záruce vydání, označte jej jako samostatné srovnání a nikdy neslučujte jeho metriky do produkčního baseline.

Také se vyhněte počítání záměrných výjimek jako ztrát, považování zahrnutí do sitemapy za důkaz indexace, testování pouze domovské stránky nebo prioritizaci pouze podle počtu URL. Definujte způsobilou množinu, segmentujte podle šablon a uchovávejte důkazy o akceptaci.

Další fáze

Další fáze, Přístupnost pro AI a připravenost pro agenty , potřebuje technicky stabilní vzorek. Předávejte zamýšlený inventář indexovatelných URL, čisté reprezentativní URL pro každou prioritní šablonu, srovnání surového a rendrovaného HTML, důkazy o robots a odpovědích, rozhodnutí o kanonických URL, známé výjimky a registr otevřených nálezů.

Netvrďte, že je web „technicky zdravý“. Uveďte, které šablony prošly bránami procházení a indexace, které zůstávají blokované a zda může publikování pokračovat. Další vlastník akceptuje, když může testovat AI-specifické user agenty a extrakci, aniž by znovu objevoval nevyřešené defekty procházení vyhledávačů.

FAQ

Jak často bychom měli opakovat technický baseline audit?

Proveďte jej před migrací, redesignem, změnou domény nebo rozsáhlým publikačním programem, poté po vydání zopakujte dotčené kontroly. Průběžně monitorujte a opakujte standardní průchod při změně šablon, navigace, renderování nebo pravidel pro kanonické URL.

Jaký poměr indexace by měl mít zdravý web?

Pro záměrně způsobilé URL je 90 % a více výchozím očekáváním, 80–90 % vyžaduje vysvětlení a pod 80 % je nález. Ze jmenovatele vylučte přesměrování, duplicity, filtry a záměrné stránky s noindex.

Můžeme publikovat obsah, zatímco probíhají technické opravy?

Pouze pokud jsou nové URL procházeny, indexovatelné, kanonikalizované, interně odkazované a neovlivněné defektem. Pokud je objevování nebo výběr blokován, pozastavte činnost; nové URL pouze rozšiřují úklid.

Potřebujeme crawler, pokud je připojena Search Console?

Ano. Search Console hlásí, co Google pozoroval; crawler testuje aktuální web a odhaluje odkazy, odpovědi, hloubku, kanonické URL a duplicity. Žádný nenahrazuje druhý.

Kdo vlastní opravy nalezené v auditu?

SEO lead vlastní registr a akceptační kritéria. Engineering obvykle vlastní opravy serveru, renderování, přesměrování, kanonických URL a HTTPS; obsahová oddělení mohou vlastnit duplicity a odkazování. Každá položka potřebuje jednu jmenovanou osobu.