Přípravy na stěhování vrcholí

pro 17 2019

S Novým rokem přichází také změna u nás ve WebMedea Services a Triton IT. Stěhujeme se z naší současné adresy ve Viktora Huga do větších prostor. Od ledna nás tak naleznete na Praze 1 v ulici Křemencova, hned vedle známé restaurace U Fleků.

Nábytek připraven k naložení - fotka

Nábytek připraven k naložení.


Provizorní připojení k internetu - fotka

Provizorní připojení k internetu.

Time to move to NFTables

pro 03 2019

The time has come for us in WebMedea to move away from the iptables firewall. While the software remains actively maintained by Netfilter, I've set my eyes upon the more recently developed nftables as it seems easier to administer and maintain rules. Nftables unifies all the separate utilities of arptables, ebtables, iptables and ip6tables into a single one. It has slightly different rule writing syntax, which can greatly shorten rules, but the principles of filtering practically remain the same.

While poking internet for a quick-to-explain guide, I've arrived (quite obviously) to the nftables wiki 10 minute guide. It literally takes 10 minutes for anyone with previous knowledge of iptables to adapt to the new syntax with this guide.

Google Marketing Platform

zář 17 2019

Google poskytuje celou řadu online služeb, které mají svou vlastní správu uživatelů. Protože každá z těchto služeb také umožňuje, aby byl uživatel členem více účtů zároveň, je udržení plné kontroly nad oprávněními často až překvapivě časově náročná činnost, která při komunikaci s novými klienty může zabrat řádově i hodiny času.

Co to je Google Marketing Platform (GMP)

Google Marketing Platform (GMP) je nástroj, který má veškerou tuto režii zjednodušit. V GMP vytváříte tzv. Organizaci, do níž lze importovat účty z dalších nástrojů od Google, konkrétně:

  • Ads
  • Analytics
  • Data Studio
  • Optimize
  • Surveys
  • Tag Manager
  • 360 varianty výše zmíněných.

Rozhodli jsme se proto GMP nasadit jako pokus ve WebMedea a otestovat jeho užitečnost.

Co GMP umožňuje

Od prvního pohledu je GMP nástroj vhodný pro větší firmy, kde již nestačí mít jeden firemní "gmail". Výhody lze shrnout v následujících bodech:

  • Společná a jednotná správa uživatelů napříč Ads, Analytics, atd...
  • Sjednocení informací o firmě využívaných v jednotlivých účtech, např. fakturace, osoba zodpovědná za řešení GDPR, apod.
  • Možnost definovat uživatelské role a jejich oprávnění místo nastavování práv každému uživateli zvlášť.

Přidání účtu z jakéhokoliv produktu Google pod GMP Vám znemožní kontrolovat uživatelská oprávnění a měnit výše zmíněné údaje přímo v této službě. Důsledky toho jsou až překvapivě nepříjemné pokud spolupracujete s externisty nebo agenturami. Konkrétně:

  • Všechny Manager účty v Google Ads jsou od Vás odpojeny a nejdou znovu spárovat. Přístup ke Google Ads už jde přidělovat jen jako standardnímů uživateli. To je velmi nepříjemné, protože tímto způsobem může být každý připojen maximálně k pěti Google Ads účtům.
  • Tím, že agentura přijde o Google Ads Manager account, ztrácí také schopnost přidělovat přístup k Vašemu účtu svým zaměstnancům. Museli by na to být administrátorem celé vaší organizace v GMP.

Shrnutí

Pokud pracujete ve velké organizaci, která řeší veškerý marketing a datovou analytiku interně, je pro Vás GMP vhodný nástroj. Jinak platformu raději nepoužívejte. Služba vytváří jen zbytečnou komunikaci a ztěžuje práci, neboť přidává další úroveň složitosti do již komplikovaných online nástrojů. Přitom by stačilo funkčně málo, aby byl nástroj opravdu užitečný. Vhodnou inspiraci lze hledat například ve Facebook Business Manageru, kde přidělením oprávnění do externí firmy umožňujete, aby ho zaměstnancům postoupila podle vlastního uvážení. Pozor si také dejte na agentury, kteří vaše účty přidají do své organizace v GMP. Stáváte se totiž jejich rukojmími: svůj účet a data nikdy neodpojíte bez jejich souhlasu a zároveň nikdy nebudete sami schopni přidělit přístup jiné firmě.

APT: The method 'ssh' is unsupported and disabled by default.

srp 23 2019

Recent Debian (and Devuan) releases have disabled ssh and rsh protocols as possible transfer method of packages. The solution to permit them again is to re-enable them in apt configuration file.

Create your own config file /etc/apt/apt.conf.d/30-ssh-transport and paste the following:

Dir::Bin::Methods::rsh "rsh";
Dir::Bin::Methods::ssh "ssh";

Package transport over both protocols should be re-enabled now.

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?