Kontrola před spuštěním webu

květen 29 2019

Lukáš nám v Tritonu připravil checklist nejběžnějších chyb, které je překontrolovat před každým předáním nového webu. Protože se ale stále rozrůstáme a jednu větu v checklistu jde interpretovat různými způsoby, rozhodl jsem se vytvořit tento blogový zápisek, který to rozepisuje trochu podrobněji.

Nahrazuji starý web? Nastavil jsem přesměrování všech původních URL?

Důležitou součástí spuštění nového webu je bezproblémový přechod návštěvníků na novou verzi. Zejména v případech, kdy měníme platformu, tj. při přechodu na jiný CMS nebo u nové implementace webu, musíme ověřit, že ze všech původních URL se dostaneme na odpovídající sekci nového webu.

Nedodržení tohoto pravidla má dva zásadní dopady:

  • Oslabení vlivu zpětných odkazů, které nyní povedou na chybovou stránku.
  • Ztráta návštěvnosti a zákazníků. Stejně jako vyhledávače, i lidé neradi přicházejí na chybovou stránku - frustrace a zmatenost z neohlášené změny webu může poškodit značku. Například u e-shopů si zákaznící rádi ukládají záložky na produktové stránky.

Fungují všechny stránky webu? Fungují všechny formuláře? A co další funkce?

Před spuštěním je bezpodmínečně nutné projít každou stránku webu a ověřit, že skutečně funguje, stejně tak i interaktivní prvky, formuláře apod.

Není nic horšího, než zjistit, že nám týden nechodily objednávky od zákazníků, protože formulář byl špatně nastaven.

Je web optimalizovaný pro vyhledávače, tj. má dobré on-page SEO?

Základní meta informace

Každá stránka webu musí obsahovat tag title a description. Title stránky odpovídá skutečnému názvu, doplňujeme ho navíc také o název webu nebo nadřazené sekce za oddělovacím znakem. U titulní stránky obvykle dáváme název webu na první místo a za oddělovač přidáváme podtitulek nebo velmi krátký popis. Pokud stránka nemá vlastní popis, který by mělo smysl použít, pak description bude obsahovat alespoň obecný popis uvedený na titulní stránce webu.

Příklad:

<title>Rychlý networking | Net Forest</title>
<meta name="description" content="Děláme rychlý networking nejen pro start-upy. Na akcích Net Forest se seznamují lidé, kteří aktivně rozvíjejí své podnikání i profesní kariéru a těší se na nové příležitosti..">

Informační architektura stránek

Každá stránka musí dodržovat logický tok HTML elementů. Nevkládáme blokové (block) prvky dovnitř řádkových (inline), každá stránka má právě jeden nadpis úrovně h1, který je obvykle shodný s obsahem title tagu bez zmínění názvu webu. Jednotlivé obsahové sekce mají svůj vlastní příslušný nadpis nižší úrovně.

Každý obrázek vložený prostřednictvím img tagu by měl mít nastaven argument alt a v něm svůj krátký textový popis.

Příklad: https://www.netforest.cz/jak-to-funguje

URL stránek

Název stránky v URL by měl kopírovat název v title a h1. Jednotlivá slova oddělujeme pomlčkou, písmena měníme na malá a odstraňujeme interpunkci, háčky a čárky.

Příklad: https://www.hlinikova-strecha.info/vite-proc-je-plechova-strecha-lepsi-volbou-nez-tasky/

Sdílení odkazů na web

Většina webů přizpůsobených pro uživatelské sdílení odkazů dnes vytváří náhled odkazovaného webu. Protože vykreslovat celý skutečný snímek obrazovky je nepraktické, sestavovaly se podobné náhledy dříve pomocí triku - stáhl se title stránky a byl doplněn o první velký obrázek a souvislý text na stránce. Dnes si ale optimalizaci sdílení můžeme zjednodušit použitím OpenGraph meta tagů. U OpenGraph jde náhled sdílení dokonfigurovat vlastními informacemi. Každý web by měl obsahovat všechny meta tagy z příkladu. Náhledový obrázek by měl být alespoň jeden.

Pro testování náhledů lze využít Facebook sharing debugger: https://developers.facebook.com/tools/debug/sharing/

Příklad: https://www.netforest.cz/

    <meta property="og:url" content="https://www.netforest.cz">
    <meta property="og:type" content="website">
    <meta property="og:title" content="Rychlý networking | Net Forest">
    <meta property="og:description" content="Děláme rychlý networking nejen pro start-upy. Na akcích Net Forest se seznamují lidé, kteří aktivně rozvíjejí své podnikání i profesní kariéru a těší se na nové příležitosti..">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo1.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo2.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo3.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo4.jpg">
    <meta property="og:image" content="https://www.netforest.cz/images/netforest-photo5.jpg">

Nastavení pro roboty, vyhledávače a odkazy vedoucí ven z webu

U každého webu jde nastavit doporučení, jak by se měly chovat programy, které jej automatizovaně procházejí. Tato pravidla fungují pouze jako přání - nejde jimi vynutit dodržování. Pravidla pro roboty jde nastavit na třech základních místech:

  • Soubor robots.txt, který je uložen ve web root složce - povolení a zákaz přístupu k dalším souborům.
  • Meta tag robots HTML dokumentu: nastavení ukládání odkazů a indexování webů.
  • Atribut rel u odkazů uvnitř HTML dokumentu: chová se stejně jako u meta tagu, ale platí jen pro tento konkrétní odkaz.

Nastavení u odkazů se týkají cílové URL ve vztahu k současné stránce, nastavení uvnitř meta tagu robots se vztahuje ke všem odkazům na současné stránce. Nastavení v robots.txt umožňuje vytvářet pravidla pro celý web nebo jeho části.

Po finálním spuštění webu je potřeba ověřit, že na žádné veřejně dostupné stránce není nastaven zákaz indexování nebo crawlingu.

Příklad meta tagu - zákaz indexování stránky a následování jejích odkazů:

<meta name="“robots“" content="“noindex,nofollow“">

Příklad robots.txt - povolení crawlingu všem robotům na celém webu s vyjímkou složky admin a jejího obsahu:

User-agent: *
Disallow: /admin

Rychlost načítání

Od moderního webu, který se zobrazuje ve vyhledávačích, se o čekává rychlé a pohodlné načítání. Všechny obrázky na webu minifikujeme tak, aby zabíraly co nejméně místa a při jejich stahování se tak přenášelo co nejméně dat. Stejně jako obrázky, minifikujeme také CSS a JS odstraněním funkčně zbytečného formátování a zkrácením názvu proměnných.

Pro minifikaci jpg, png a gif obrázků lze využít web TinyPNG: https://tinypng.com/, v CMS systémech jsou dostupné minifikační pluginy.

Pro minifikaci skriptů a grafických stylů lze použít https://www.minifier.org/, lepší je ale nastavit si automatickou minifikaci ve vývojovém prostředí.

Pro testování rychlosti lze využít Google PageSpeed Insights: https://developers.google.com/speed/pagespeed/insights/?hl=cs

Je web zabezpečený? Chrání před spamem?

Nastavení HTTPS

Všechny weby, které spouštíme pro klienty, musí mít na finální doméně nastaven přístup přes HTTPS na portu 443. Verze bez šifrování na portu 80 musí na šifrovanou verzi přesměrovávat a to tak, že mění protokol a zachová zbytek původní URL.

Na našem serveru nastavujeme přesměrování pomocí konfigurace web serveru NGINX. Na externím hostingu většinou běží Apache HTTP server, který můžeme dokonfigurovat souborem .htaccess ve web root složce webu (tečka na začátku značí skrytý soubor v Linux / Unix systémech).

Příklad - pravidlo pro vynucení www a https před názvem domény:

RewriteEngine On

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{ENV:HTTPS} !^.*on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

HTTPS certifikát u webů citlivých na utajení dat nakupujeme a nebo používáme certifikáty vystavené certifikační autoritou Let's Encrypt. K nasazení certifikátů od Let's encrypt používáme automatizační nástroj certbot a jeho plugin pro webový server NGINX python-certbot-nginx.

Pokud nasazujeme Let's encrypt certifikát někam, kde nejde použít certbot, musíme ručně sestavit žádost (CSR) a odeslat ji na servery Let's encrypt, ručně provést ověření domén a pak hotový certifikát nasadit. Proces jde usnadnit použítím webové aplikace jako jako zerossl.com.

Obfuskace e-mailů

Všechny veřejně viditelné emailové adresy na webu musí být upraveny, aby je spamboti nemohli jednodušše přečíst Nejjednodušší metoda, jak toho docílit, je sestavení finálního textového řetězce (klikatelného) emailu pomocí javascriptu. Nejběžnější webové scrapery neumí javascript interpretovat.

Příklad obfuskace kontaktního emailu z webu tritonit.cz:

<script type="text/javascript"><!--
    var ivntlhw = ['t', 'i', 'e', 't', 'a', 'c', '"', 't', 's', '@', 't', ' ', '<', 'a', '"', '@', 'r', 'o', 'm', 't', 'i', ':', 'o', 'r', 'c', 'o', '<', ' ', 'i', 'i', '.', 'z', 't', 't', 'c', 'a', '=', 's', 'l', 'n', 'i', 'z', 'n', '/', 'o', 'f', 'f', 'e', '>', '>', 'n', 'm', 'i', 'o', 'n', 'h', 'l', 'a', 'i', 'l', 'i', '.', '=', 'f', '"', 'r', 'a', '"'];
    var schidlm = [60, 55, 41, 13, 36, 30, 8, 56, 37, 20, 53, 2, 64, 66, 40, 52, 4, 57, 42, 21, 16, 15, 14, 54, 34, 25, 0, 33, 23, 59, 29, 63, 28, 24, 62, 1, 39, 38, 12, 49, 48, 31, 17, 65, 19, 50, 18, 5, 47, 67, 26, 9, 11, 51, 58, 3, 35, 43, 27, 45, 44, 61, 7, 6, 32, 22, 10, 46];
    var bwmotom = new Array();
    for (var i = 0; i < schidlm.length; i++) {
        bwmotom[schidlm[i]] = ivntlhw[i];
    }
    for (var i = 0; i < bwmotom.length; i++) {
        document.write(bwmotom[i]);
    }
    // -->
</script>
<noscript>
  Pro zobrazení emailové adresy, prosíme, zapněte JavaScript.
</noscript>

Ochrana formulářů

Všechny veřejně dostupné formuláře potřebují antispamovou ochranu. V případě použití CMS systému (Wordpress) můžeme ochranu svěřit pluginu pro vytváření těchto formulářů. V případě tvorby webu od začátku je potřeba alespoň nějakou ochranu vytvořit ručně.

Nejjednodušší metoda ochrany je přidání skrytých polí do formuláře tak, že je robot nedovede rozeznat od zbytku.

Nastavil jsem měření návštěv?

Až na naprosté výjimky měříme u všech webů návštěvnost uživatelů. Tyto informace jsou v internetovém marketingu velmi důležité neboť nám umožňují přízpůsobit web na základě chování návštěvníků, analyzovat, co nám přináší nejvíce peněz, nebo zacílit na určitou skupinu podrobnější reklamu.

Google Tag Manager & Google Analytics

Na všech webech nasazujeme kód Google Tag Manager. Ten nám dovoluje spravovat kódy ostatních služeb přehledně z jednoho místa ve webovém prohlížeči, aniž bychom museli zasahovat do zdrojového kódu webu. Společně s Google Tag Managerem automaticky nasazujeme i základní měření Google Analytics, a to prostřednictvím tagu Universal Analytics s nastaveným měřením Page View.

Měření konverzí

Pokud vytváříme web, vždy tím sledujeme nějaký cíl nebo úkol, který bude web vykonávat. K ověřování plnění tohoto cíle slouží konverze. Rozplánování konverzí bychom měli řešit už při designové fázi webu. Během vývoje pak musíme zajistit, že jsou jednotlivé cíle měřitelné - tzn., že existuje způsob, kterým web dá vědět, že uživatel právě splnil vytyčený cíl.

Konverze si pomyslně dělíme na měkké a tvrdé. Tvrdou konverzí rozumíme úplné splnění úkolu webu - například dokončení prodeje zboží v e-shopu, odeslání poptávkového formuláře, nebo využití mzdové kalkulačky. Měkkou konverzí rozumíme buď splnění vedlejšího úkolu webu (přečtení celého článku, prohlédnutí kontaktních osob firmy), nebo dokončení významného kroku na cestě ke tvrdé konverzi, například ověření dostupnosti internetu, začátek vyplňování kontaktního formuláře, apod.

Měkké konverze obvykle využíváme k rozhodování, jak budeme s návštěvníkem nebo zákazníkem dále pracovat. Pokud někdo přidal zboží do košíku, mohl by nákup ještě dokončit, pokud si ověřil dostupnost služby, mohl by si ji ještě objednat.

Je všecho v pořádku s obsahem webu?

Na úplný závěr je potřeba sebekriticky znovu projít web. Skutečně vše vypadá dobře a na 100% funguje? Vypadá web tak, abych na něj mohl být hrdý? Nezapoměl jsem na žádnou funkci?

Odstranění testovacích dat

Odstranil jsem všechna testovací data a stránky? Co debugové výpisy do logu nebo konzole prohlížeče? Přepnul jsem web na produkční režim? Co databáze a číselníky v ní - jsou zde nahrána správná data?

Korektura textu

Jsou všechny texty gramaticky správně - bez hrubek a překlepů? Nezarovnává se někde podivně text na více řádků? Dávají všechny texty smysl? Kolik lidí si web pročetlo - můžu opravu věřit jen sobě nebo jedné další osobě? Odkazují se stránky na webu jedna na druhou v rozumné míře? Jsou odkazy vedeny z důležitých slov pro web - například běžných nákupních frází z vyhledávání?

Ošklivá grafika

Odpovídá grafika původnímu záměru designera? Skutečně se web zobrazuje správně na všech typech zařízení a v různých prohlížečích? Co dočasné fotografie a obrázky - vypadají dobře? Mám zajištěný termín dodání finálních fotografií od klienta?

Emaily na vlastní doméně - díl 2: naše řešení

lis 21 2017

Po zjištění z minulého dílu jsme se v Triton IT rozhodli nasadit vlastní mail server. Z běžně používaných řešení je ale pouze Microsoft Exchange Server dostupný jako kompetní balík všeho, co je potřeba. MS Exchange Server samozřejmě představuje nemalou investici a funguje jen na zařízeních s operačním systémem Windows Server. Vzhledem k našim požadavkům na nízkou cenu nezbývá, než ho přeskočit a podívat se na celé téma podrobněji.

Pro úspěšný běh vlastního mail serveru na internetu je potřeba jen následující tři kusy software:

  • MTA: Mail Transfer Agent vyměňuje emaily po internetu. Funguje jako server i klient nad protokolem SMTP. Příkladem MTA jsou programy sendmail, postfix a exim4. V podstatě má jen dva úkoly:
    • jako klient se připojí k jinému MTA a doručí mu email.
    • jako server čeká, až mu někdo (např. jiný MTA) doručí email. Pak se rozhodne, jestli ho někam uloží, nebo ho jde poslat dál.
  • MDA: Mail Delivery Agent umožňuje uživatelům stahovat emaily ze serveru. Konkrétně povoluje klientským programům (MUA) se připojit prostřednictvím protokolů IMAP nebo POP3 ke schránkám uživatelů. Teoreticky také může schránky a uživatele spravovat, to je něco, co ale umí i někteří MTA a obecně není jasně dáno, kdo to má mít starost.
  • MUA: Mail User Agent je program, s kterým pracuje uživatel. MUA má zpravidla hezké grafické rozhraní s přehledem emailů ve schránce, ukládá si kontakty, umožňuje snadno přikládat přílohy, atd. Mezi MUA patří MS Outlook, Thunderbird, ale i GMail.com a Seznam.cz.

Když si oddělíme databázi našich uživatelů a samotné úložiště schránek, jde to celé nakreslit asi takto:

Náčrt propojení programů a služeb v mail serveru

Při návrhu se největším úskalím ukázalo být vyzvedávání emailů pomocí MUA z MDA. Přestože komunikace přes protokoly POP3 a IMAP je naprosto přímočará a jasně definovaná, některé MUA se rozhodly zavést si vlastní dodatečná pravidla k formátu uživatelských jmen a šifrování. Konkrétně:

  • MS Outlook nefunguje, dokuď nemá uživatelská jména pro komunikaci s MDA jen v alfanumerickém tvaru, tj. bez symbolu @ (nelze použít email jako přihlašovací jméno).
  • GMail protestuje, pokud TLS komunikace není realizována pomocí certifikátu od některé z mezinárodních certifikačních autorit. Certifikát od Let's encrypt v době našeho testování (2016) bohužel nebyl podporován.

Finální řešení

Po dlouhém výzkumu metodou pokus-omyl jsme došli k následujícímu rozvržení:

  • MTA = postfix
  • MDA = dovecot
  • MUA = co má kdo rád, za mě jednoznačně GMail
  • Schránka = složka na serveru, kompletně v režii postfix a dovecot
  • Databáze emailových účtů = MySQL databáze

Tím jsme dosáhli následujících nákladů:

  • 110 Kč / měsíc ... Virtuální server, na kterém už stejně provozujeme weby
  • 259 Kč / rok ... Certum Commercial SSL certifikát
  • 130 Kč / rok / doména ... Náklady na CZ doménu placené registrátorovi

Jakých výhod jsme tímto řešením dosáhli?

  • Libovolný počet domén, schránek, aliasů bez poplatků navíc.
  • Možnost napojit oblíbenou schránku na webu nebo program úplně podle vlastní preference zaměstnance.
  • Při používání GMailu dále:
    • Snadné spojení více firemních i soukromých schránek do jediného účtu
    • Automatické ukládání kontaktů a jejich sdílení do Android zařízení
  • Téměř bezúdržbový běh
  • Při použítí POP3 k vyzvedávání schránky - téměř nulové nároky místo při zálohování, zodpovědnost za uložené emaily lze přesunout na jinou (i placenou) službu.

V příštím díle se podíváme na běžné problémy, se kterými se setkáte po nasazení vlastního mail serveru. A že jich není málo.

Veletrh For Arch 2017

zář 23 2017

Včera jsem navštívil veletrh For Arch. Moje první kroky vedly k velkému stánku našeho milovaného klienta. Opět jsem si s nimi příjemně popovídal, pořešil několik pracovních záležitostí a občerstvil se u jejich baru :)

Potom jsem si procházel zbytek veletrhu. S WebMedeou jsem si připadal tak trochu jako terminátor s infravizí. Proč? Stačilo zadat název od libovolného stánku do mobilu a hned jsem ve WebMedea viděl, kde se firma propaguje, do jakého propagačního kanálu investuje a zhruba kolik, kde jsou její slabá místa a prostor pro zlepšení.

Zastavil jsem se u několika stánků, s majiteli si chvíli pokecal a dozvěděl se řadu zajímavých informací. Tak například automatických kotlích na štěpku nebo luxusních vířivých vanách. Odcházel jsem s dobrou náladou a pár zajímavými vizitkami.

Emaily na vlastní doméně - díl 1: externí poskytovatelé

zář 09 2017

Jako jedna z prvních věcí, které jsme řešili při zakládání Triton IT, byla schopnost odesílat a přijímat emaily na vlastních doménách. Malicherný problém, který lze většinou vyřešit v ceně domény nebo hostingu. U Tritonu se ale problém ukázal být mnohem větší. Naše definice pohodlného ovládání se také postupně vyvíjela, neboť že vám něco není pohodlné většinou zjistíte až po vyzkoušení. Po mnoha pokusech a změnách jsme zakotvili na následujících požadavcích:

  • Co nejnižší cena.
  • Libovolný počet schránek a domén bez zvýšení nákladů na provoz.
  • Možnost používat libovolného klienta podle preference zaměstnance -  tj. Gmail, Seznam, MS Outlook, Thunderbird (pro PGP šifrování), atd.
  • Vytváření aliasů (emailových adres, které jsou jen přezdívkou pro jednu nebo více dalších adres).
  • Sdílení kontaktů mezi emailovým klientem a telefonem.

Externí řešení k dispozici

Protože jsme se hned nechtěli pouštět do budování vlastního serveru, hledali jsme nejprve externí řešení. V následující tabulce je seznam toho, co jsme buď vyzkoušeli, nebo to zvažovali:

Služba Cena Výhody Nevýhody
Google for business / GSuites 4 Eur / měsíc / schránka Synchronizace kontaktů s Androidem, větší Google Drive v ceně, GMail + jeho mobilní aplikace Drahé, nejde dělat aliasy pro jiné domény, tj. domény na kterých není placená schránka.
Jiné zahraniční nabídky 2 až 5 Eur / měsíc / schránka Obecně nejde dělat aliasy pro jiné domény než ty, na kterých se platí alespoň jedna schránka.
Seznam Zdarma Jediné řešení úplně zdarma. Vynucuje používání Seznam web klienta nebo jejich mobilní aplikace. Tím pádem nelze používat s GMail apod.
Active24 59 Kč / měsíc / 5 schránek / doména + 9 Kč / měsíc / další schránka Pohodlná administrace společně s doménou a případným web hostingem. Aliasy jiných domén za příplatek.
Wedos V ceně Webhostingu, tj. 30 Kč / měsíc. Místo počtu schránek je limitem úložný prostor, pohodlná administrace společně s doménou a web hostingem. Nelze vytvářet aliasy pro jiné domény, to by vyžadovalo zakoupit k nim webhosting.

V uvedených cenách nejsou náklady na doménu, které jsou různé podle prodejce. Ceny naposled aktualizovány 2016.

Účtování za každou doménu a nízká flexibilita aliasů pro nás byly kamenem úrazu. Nezbývalo nám nic jiného než postavit alespoň částečně vlastní řešení, a na to se podíváme příště.

Jak na produktový feed, který obsahuje neplatné znaky

srp 25 2017

Odladit produktový feed u zákazníka, který ho nasazuje poprvé, dá zabrat. Když je k nasazení změn nutno zákazníka pokaždé kontaktovat, nebo dokonce předat hlášení třetí straně, může se odladění feedu tak, aby ho Google Merchant Center přijal, natáhnout až na týdny. Vy ale potřebujete feed funkční ihned a produktovou kampaň spuštěnou ideálně včera.

V Triton IT jsme řešili právě takový problém. Popisky produktů načtené z e-shopu obsahovaly znaky neplatné v kódování UTF-8. Google se proto jednoduše rozhodl, že zahodí celý zbytek feedu po výskytu takového znaku.

K vyřešení podobného problému ale úplně stačí mít po ruce vlastní hosting s podporou CGI - např. PHP. Soubor s následujícím kódem jsme nasadili na náš web, a můžeme tak feedy automaticky čistit od nežádoucích znaků:

<?php

if (!isset($_GET['f']) || $_GET['f'] == null) {
  header('Content-Type: text/plain');
  echo 'No feed provided';
  exit(1);
}

$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $_GET['f']);
curl_setopt ($ch, CURLOPT_HEADER, 0);
ob_start();
curl_exec ($ch);
curl_close ($ch);
$xml = ob_get_contents();
ob_end_clean();

header('Content-Type: text/xml');
echo preg_replace('/[\x00-\x1F\x7F]/u', '', $xml);
exit(0);

Původní odkaz v Merchant Centru jsme jednoduše nahradili odkazem na náš vlastní web: www.domena.cz/?f=url_na_puvodni_feed a vše hned fungovalo.

Méně výkonné hostingy mohou mít problém s feedy o mnoha produktech, i ten náš ale zvládá zpracovat feedy do 1000 položek pod 1s. Vzhledem k frekvenci stahování jedenkrát denně to nepředstavuje žádnou zátěž.