Ochrana testovacích prostředí ve zkratce

Pokud se chcete vyhnout trapným a nepříjemným situacím, zajistěte, aby vaše testovací prostředí byla řádně chráněna.

Nejlepším způsobem zabezpečení je HTTP autentizace.

Zaindexovaly vaše testovací prostředí vyhledávače? Nezoufejte. V tomto průvodci se dozvíte, jak to rychle a a účinně napravit.

Vídáme to každý den: testovací či vývojářská prostředí obsahující nedokončené webové stránky ve fázi vývoje, která jsou zcela volně přístupná, a kdokoli na světě si je tak může prohlédnout. A aby toho nebylo málo, vyhledávače je mnohdy ještě zaindexují!

Nevěříte?

Mrkněte na tento vyhledávací dotaz inspirovaný tweetem Petera Nikolowa (sledujte ho, je vtipný i chytrý zároveň!).

Proč je volně dostupné testovací prostředí problém

O problém jde dokonce hned na dvou rovinách: na rovině SEO a na obchodní rovině celkově.

Obchodní rovina

Chcete, aby ostatní mohli zhlédnout váš “lorem ipsum” obsah a smát se vám, nebo, nedej bože, aby si mohli přečíst oznámení o obří akvizici či rebrandingu, které mělo být až do spuštění nového webu tajemstvím?

Je to jednak neprofesionální, a především to není chytré. Některé agentury tyto chyby dokonce využívají jako součást své strategie: vyhledávají další agentury, které je dělají, a poté osloví jejich klienty, kdy tuto trapnou situaci využijí ve svůj prospěch.

Rovina SEO

Kromě ztrapnění před klienty může dojít také k problémům s duplicitním obsahem, pokud je testovací prostředí velmi podobné prostředí produkčnímu a vyhledávače ho zaindexují.

Veřejně dostupné a zaindexované testovací prostředí je však zcela zbytečná chyba, které lze velmi snadno předejít. V tomto článku vám ukážeme, jak testovací prostředí chránit, jaké metody k tomu můžete využít a co dělat, pokud vaše testovací prostředí již bylo zaindexováno.

Od této chvíle platí, že kdykoli použijeme označení testovací prostředí, je tím myšleno jak testovací, tak vývojářské prostředí.

Co to testovací a vývojářská prostředí vlastně jsou?

Když pracujete na zcela novém webu či nové funkcionalitě, nezasahujete do ostré verze webu (známé také jako „produkční prostředí”), protože by mohla velmi snadno přestat fungovat. Nejlepším postupem je tedy pracovat s jinými, oddělenými prostředími, kde nové funkcionality vyvíjíte a testujete.

Jaká prostředí kromě produkčního tedy existují?

  • Vývojářské prostředí: V tomto prostředí vývojáři nejprve testují kód. Toto testování provádí často lokálně na svých počítačích, což znamená, že v tomto případě se rizika volné dostupnosti a indexace tohoto prostředí není třeba obávat. Pokud však toto prostředí není dostupné pouze lokálně a nachází se například na subdoméně dev.example.com, zmíněné riziko dostupnosti a indexace zde naopak hrozí.
  • Testovací prostředí: V tomto prostředí jsou nové funkcionality nanečisto testovány před ostrým nasazením. Nový obsah je publikován nejprve zde, aby bylo možné zkontrolovat, zda vypadá tak, jak má. Testovací prostředí většinou není lokální, protože do něj potřebuje přístup více členů týmu, a proto se zpravidla nachází na subdoméně či samostatné doméně.

Tip: Vzhledem k tomu, že si čtete o ochraně testovacích prostředí, se v brzké době možná chystáte provést migraci webu. Pokud chcete, aby proběhla jako po másle, mrkněte na našeho průvodce migracemi webů, který zajistí, že během procesu migrace nezapomenete na žádný důležitý krok!

Security through obscurity není řešením

Security through obscurity neboli bezpečnost skrze utajení představuje postup, kdy své „tajné” testovací prostředí chcete chránit tak, že o něm nikomu neřeknete. Tato strategie však zdaleka není ideální, obzvláště v případě, že se jedná o jedinou úroveň zabezpečení.

Co když někdo omylem zveřejní odkaz na toto testovací prostředí? Nebo do produkčního prostředí omylem nasadí kód obsahující atributy canonical či hreflang, které na něj odkazují?

Takto nechráněné testovací prostředí nejenže způsobí problémy v produkčním prostředí, ale zároveň ho zaznamenají i vyhledávače a zařadí ho do fronty pro crawlování, pokud jim to neznemožníte zamezením přístupu či poskytnutím pravidel pro crawlování, kterými se budou řídit.

Jak lze vývojářská a testovací prostředí chránit

Nyní je tedy již jasné, proč je vývojářská a testovací prostředí nutné chránit. Jak to ale udělat? Způsobů zabezpečení existuje hned několik. Jak z nich však vybrat ten nejlepší?

Abychom vám toto rozhodování usnadnili, projdeme si klady a zápory všech metod dle následujících kritérií:

  • Uživatelská přívětivost: množství úsilí navíc, které daná metoda vyžaduje.
  • Přístup třetích stran: do jaké míry daná metoda zabraňuje v přístupu do testovacího prostředí třetím stranám.
  • Podpora SEO: do jaké míry daná metoda zabraňuje vyhledávačům v crawlování a indexaci testovacího prostředí.
  • Podpora monitoringu: do jaké míry vám daná metoda umožní monitorovat testovací prostředí pro účely SEO.
  • Riziko lidské chyby: do jaké míry je daná metoda náchylná k lidským chybám ovlivňujícím SEO.
Metoda Uživatelská přívětivost Přístup třetích stran Podpora SEO Podpora monitoringu Riziko lidské chyby
HTTP autentizace no no no no no
VPN no no no no no
Direktivy robots no no no no no
Robots.txt no no no no no
Kanonické odkazy no no no no no
Povolení konkrétních uživatelských agentů no warning no no no

Metoda č. 1: HTTP autentizace – vaše nejlepší volba 🏆

Nejlepším způsobem, jak uživatelům i vyhledávačům zabránit v přístupu do vašeho vývojářského a testovacího prostředí, je využití HTTP autentizace. Tuto autentizaci je však důležité implementovat pomocí protokolu HTTPS, protože jistě nechcete, aby uživatelská jména a hesla byla přenášena jako prostý text.

Doporučujeme udělit výjimku IP adresám ve vaší kanceláři a externím stranám a členům týmu pak poskytnout přístup přes uživatelské jméno a heslo.

Tímto krokem zajistíte, že se vyhledávače k ničemu nedostanou, a vy navíc získáte kontrolu nad tím, kdo má kam přístup. Své testovací prostředí můžete vytvořit se stejným souborem robots.txt, který využíváte v produkčním prostředí, a také se správnými direktivami robots a kanonickými odkazy. Při monitoringu problémů a změn v testovacím prostředí před ostrým nasazením tak získáte reálný a přesný obraz situace.

Zároveň také předejdete riziku, že vývojáři do produkčního prostředí zapomenou nasadit správné direktivy robots, soubor robots.txt a kanonické odkazy, což je další předností této metody.

Jedná se o mnohem lepší postup než využití souboru robots.txt a/nebo direktiv robots noindex a kanonických odkazů, protože tyto direktivy nezabraňují v přístupu ostatním lidem, a dokonce ani vyhledávače je občas nedodržují.

Při použití HTTP autentizace je navíc stále možné využívat testovací nástroje Googlu jako Test stránek AMP, Test použitelnosti v mobilech a Nástroj na testování strukturovaných dat. Stačí nastavit tunel.

Jak HTTP autentizaci nastavím?

Níže najdete několik zdrojů, které vám poskytnou informace a návody k nastavení HTTP autentizace u Apache, nginx a IIS:

Dean Cruddace
Dean Cruddace
Cultured Digital

Své testovací prostředí chraňte heslem, to je celé. Nic extra, prostě ho zaheslujte. Google nevidí na druhou stranu tohoto zabezpečení (pokud nenastavíte tunel pro testovací účely). I když používáte direktivy robots.txt Disallow: / a meta robots noindex, může dojít k indexaci stránek, pokud na ně směřuje dostatek odkazů či jiných signálů.

Metoda č. 2: přístup přes VPN

Zkratka VPN znamená “virtual private network” neboli virtuální privátní síť. Tato síť funguje v principu tak, že svůj lokální počítač propojíte se sítí své firmy, aby se stal její součástí. A jakmile jste součástí firemní sítě, máte přístup do testovacího prostředí. Nikdo, kdo do této sítě není připojen, se do něj nedostane. To znamená, že přístup k testovacímu prostředí nemohou mít ani třetí strany ani vyhledávače.

Přístup přes VPN nabízí z velké části stejné výhody jako HTTP autentizace, má však oproti ní jednu velkou nevýhodu. Nástroje pro SEO monitoring, které nejsou provozovány lokálně, nemusí fungovat správně, či dokonce vůbec. Nemít možnost sledovat pokroky svého vývojářského týmu není ideální, a pokud se staráte o skutečně velké weby, jedná se o zásadní problém.

Metoda č. 3: Direktivy robots

Direktivy robots slouží k informování vyhledávačů o preferencích týkajících se crawlování a indexace. Vyhledávače můžete například požádat, aby neindexovaly určité stránky či nesledovaly určité odkazy.

Direktivy robots můžete definovat buď v HTTP hlavičce stránky (X-Robots-Tag header), nebo v sekci <head> (direktivy meta robots). Vzhledem k tomu, že vaše testovací prostředí bude kromě stránek obsahovat také jiné druhy obsahu, doporučujeme vždy používat X-Robots-Tag v HTTP hlavičce, který zajistí, že ostatní obsah jako například soubory PDF nebude zaindexován.

Direktivy robots jsou, jak už napovídá jejich název, určeny pro roboty („crawlery”), a nezabraňují tak v přístupu třetím stranám. Dávají poměrně silný signál vyhledávačům, aby vaše stránky neindexovaly. Výraz „poměrně” volíme proto, že vyhledávače se i tak mohou rozhodnout tyto direktivy ignorovat a vaše stránky zaindexovat. Toto řešení zároveň nepodporuje ani monitoring, protože podobně jako u souboru robots.txt může vést k tomu, že SEO nástroje budou chybně hlásit problémy.

K tomu všemu je zde obrovské riziko lidské chyby. Velmi často se totiž stává, že jsou direktivy z testovacího prostředí omylem přeneseny také do produkčního prostředí.

Metoda č. 4: Robots.txt

Soubor robots.txt obsahuje pravidla, podle kterých crawleři prochází váš web. I pomocí tohoto souboru tedy můžete vyhledávače požádat, aby nevstupovali do vašeho testovacího prostředí, což se nejčastěji provádí uvedením následujících instrukcí:

User-agent: * Disallow: /

Tímto krokem zabráníte vyhledávačům v crawlování dané části webu, avšak pokud crawleři najdou odkazy, které na tuto část webu vedou, mohou ji stále zaindexovat, což vyústí ve výsledky jako například tento:

Google description not available robots.txt

Někteří lidé ve svých souborech robots.txt uvádí také neoficiální direktivu Noindex, což však nedoporučujeme. Vzhledem k tomu, že jde skutečně o neoficiální direktivu, je pro účely znepřístupnění testovacího prostředí vhodnější využít direktivu Disallow.

Soubor robots.txt neposkytuje žádnou ochranu proti přístupu třetích stran, a může navíc rozhodit také nástroje pro SEO monitoring, které tak mohou chybně hlásit problémy. K tomu všemu je zde obrovské riziko lidské chyby, protože může opět dojít k přenosu souboru robots.txt z testovacího prostředí do produkčního.

Metoda č. 5: Kanonické odkazy

Kanonický odkaz informuje vyhledávače o kanonické verzi stránky. Pokud tedy stránky v testovacím prostředí odkazují na stránky v produkčním prostředí jakožto na kanonické, všechny signály by měly být konsolidované v produkčním prostředí.

Kromě toho se kanonické odkazy svou funkcí podobají direktivám robots, a to především co se týče nevýhod:

  • Nezabraňují třetím stranám v přístupu do testovacího prostředí.
  • Nepodporují monitoring – mohou způsobit chybná hlášení SEO nástrojů.
  • Rovněž je zde riziko lidské chyby, protože stejně jako v minulých případech může dojít k nechtěnému přenosu direktiv canonical z testovacího do produkčního prostředí.

Metoda č. 6: Povolení konkrétních uživatelských agentů

Povolení přístupu konkrétním uživatelským agentům lze využít například pro umožnění monitoringu testovacího prostředí SEO specialistům, pokud jejich nástroje podporují vytvoření vlastních uživatelských agentů. Tomuto nově vytvořenému agentovi lze pak udělit výjimku, zatímco všichni ostatní agenti (včetně prohlížečů) budou zablokováni.

Tento postup však nelze označit za uživatelsky přívětivý, protože ztěžuje proces manuálního ověření v prohlížeči. A ani bezpečnost zde není úplně zaručena: Pokud jistá třetí strana ví, že pracujete pro firmu X a zároveň ví, jakého uživatelského agenta využíváte (může jít například o nespokojeného zákazníka), může do vašeho testovacího prostředí proniknout.

Jak zjistím, že vyhledávače mé testovací prostředí indexují?

Existuje několik způsobů, jak můžete indexaci testovacího prostředí odhalit. Následující dva postupy jsou však nejjednodušší a nejvyužívanější:

Možnost č. 1: dotaz s parametrem site

Pokud se vaše testovací prostředí nachází na subdoméně, můžete zkusit zadat vyhledávací dotaz jako například tento: site:example.com -inurl:www

Ve výsledcích uvidíte všechny Googlem zaindexované stránky na doméně example.com kromě stránek obsahujících “www”.

Zde je odkaz na výše uvedený ilustrační dotaz.

Možnost č. 2: Google Analytics

Pokud neznáte URL adresu svého testovacího prostředí, můžete nahlédnout do Google Analytics:

  • Jděte do menu Publika > Technologie a vyberte Síť.
  • Jako Primární dimenzi vyberte Název hostitele.
  • Hledejte názvy hostitele, které mají jinou doménu nebo obsahují subdomény jako staging, test či dev.

Možnost č. 3: Google Search Console

Díky konsolidaci služeb v Google Search Console lze nyní mnohem snáze objevit stránky, které by neměly být indexovány.

Nezáleží na tom, zda se vaše testovací prostředí nachází na vlastní oddělené doméně, subdoméně či v podadresáři - pokud jste danou doménu ověřili, budete si moci zobrazit všechny zaindexované stránky a také všechny dotazy, pro které se tato doména umísťuje. Tyto informace najdete v následujících sekcích GSC:

  • Výkon > Vyhledávací dotazy
  • Výkon > Stránky
  • Index > Zahrnutí do indexu

O tento postřeh se s námi podělili Rhea Drysdaleová a Martijn Oud, za což jim tímto děkujeme!

Rhea Drysdale
Rhea Drysdale

Propojení testovacího prostředí s Google Search Console vám poskytne přehled o tom, zda nějaká z jeho součástí nebyla zaindexována, a zároveň vám umožní tyto nežádoucí URL adresy z indexu rychle odstranit. Kromě toho pak zavádíme také kombinaci HTTP autentizace a direktiv v souboru robots.txt, která zajistí, že se testovací prostředí nedostane do výsledků vyhledávání. U adres URL obsahujících přihlašovací údaje (https://user:[email protected]) hrozí, že budou crawlovány a zaindexovány poté, co jsou omylem sdíleny prostřednictvím e-mailu či sdílených dokumentů.

Musíme tedy zajistit, aby crawleři obdrželi jasné instrukce neindexovat nic z testovacího prostředí. V případě, že HTTP autentizace s uživatelským jménem a heslem není pro klienta proveditelnou možností, se nám velmi osvědčil whitelisting IP adres klienta a firmy. ContentKing a jeho monitoring souboru robots.txt nám již několikrát zachránil krk, když ho developeři omylem upravili či smazali.

Jak dostat již zaindexované testovací prostředí z indexu

O ou. Vyhledávače vaše testovací prostředí již zaindexovaly a vy máte za úkol to napravit. Máme pro vás však dobrou zprávu: pokud budete postupovat podle následujících kroků, zvládnete to poměrně snadno.

Krok 1: skrytí z výsledků vyhledávání

Ověřte testovací prostředí v nástrojích pro webmastery jako Google Search Console a Bing Webmaster Tools a využijte nástroj pro odstranění adres URL (viz dokumentace Googlu a dokumentace Bingu). Google tento požadavek obvykle vyřídí během několika hodin (Bingu to trvá trochu déle), a poté se vaše testovací prostředí již nebude zobrazovat v žádných výsledcích vyhledávání. Je tu však háček: testovací prostředí je stále zaindexováno, jen se nezobrazuje. Toto skrytí trvá v případě Googlu pouze 90 dní. Během tohoto období je tedy nutné zajistit odstranění příslušných stránek z indexů vyhledávačů tím správným způsobem: direktivou robots noindex.

Krok č. 2: implementace direktivy noindex

Zajistěte, aby direktiva robots noindex byla implementována na každé stránce testovacího prostředí. V logovacích souborech serveru pak sledujte požadavky crawlerů na dříve zaindexované stránky (které jsou nyní opatřené direktivou noindex), abyste se ujistili, že vaše instrukce „pochopili”.

Ve většině případů stačí pro vyslání signálu vyhledávačům, aby odstranily stránky testovacího prostředí ze svých indexů, zmíněných 90 dní. Pokud by však tato doba náhodou nestačila, jednoduše celý proces zopakujte.

Jakmile je testovací prostředí z indexů odstraněno, zabezpečte ho pomocí HTTP autentizace, která zajistí, že se tento problém nebude již nikdy opakovat.

Další užitečné zdroje

Zde je také několik dalších užitečných zdrojů, které vám s ochranou testovacího prostředí pomohou:

Nepřestávejte se učit!

Na své nově nabyté znalosti o nejlepším způsobu ochrany testovacích prostředí můžete nyní navázat následujícími články:

ContentKing Academy Content Team
Steven van Vessum
Steven van Vessum

Steven je CCO společnosti ContentKing. To znamená, že se stará o všechno spojené se zákazníky a inbound marketingem. Takže je přesně tam, kde chce být. Baví ho zlepšovat pozice webů ve vyhledávačích a rád mluví o inbound marketingu.

Vojtěch Zach
Vojtěch Zach

Vojtěch se v ContentKingu stará o zákaznickou podporu a lokalizaci. Právě on vám rád odpoví na všechny otázky, když se nás rozhodnete kontaktovat. A protože je vystudovaný překladatel, kromě dělání radosti našim uživatelům ho baví také překonávat výzvy spojené s lokalizací naší aplikace.

Lorena Torsani
Lorena Torsani

Lorena v ContentKingu působí jako specialistka marketingu. Je to kreativní duše, která se vyžívá v přinášení čerstvých nápadů a ve vytváření nevšedních kampaní, prostřednictvím kterých komunikuje s našimi zákazníky.

Získejte zkušební verzi na 14 dní zdarma

Začněte během 20 vteřin

Vložte platnou doménu, prosím (www.priklad.cz).
  • Platební karta není potřeba
  • Není třeba žádná instalace
  • Bez závazků