До основного вмісту
Olexa Studio.

Глосарій вебмайстра

Слова, які ви почуєте від будь-якої студії, включно з нашою. Пояснені так, як пояснюють знайомому: без «інстансів» і «сутностей», з прикладом там, де він чесний. Якщо після якогось означення лишилось питання — це наша хиба, напишіть, перепишемо.

Основи

Домен
Адреса сайту, яку людина набирає в браузері.
Домен — це olexastudio.com: ім’я, за яким вас знаходять. Він орендується на рік або кілька і продовжується щоразу; якщо не продовжити, сайт зникає з мережі, хоч файли лишились на місці. Домен не прив’язаний до виконавця: він оформлений на вас і переїжджає разом із вами.
Хостинг
Місце, де фізично лежать файли сайту й працює його код.
Домен — це адреса, хостинг — сама будівля. Сайт лежить на чужому комп’ютері, який працює цілодобово й віддає сторінки всім, хто про них попросив. Оплата теж періодична; на відміну від домену, хостинг можна змінити на інший за один вечір, і відвідувач цього не помітить.
Лендинг
Одна довга сторінка з єдиною дією, до якої вона веде.
Лендинг не має меню з десятьма розділами: він розповідає одну історію згори вниз і закінчується однією кнопкою — заявка, дзвінок, купівля. Його роблять під конкретну рекламу чи послугу. Якщо потрібні каталог, блог і кілька напрямів — це вже не лендинг, а сайт.
Адаптивність
Здатність сторінки перебудовуватись під екран телефона, планшета й ноутбука.
Це не «зменшена копія» — блоки міняють порядок, меню згортається, колонки стають одна під одною. Більшість відвідувачів приходить із телефона, тож перевіряти роботу треба саме там, а не на великому моніторі розробника. Адаптивність не коштує окремо: сторінка або зроблена так, або зроблена погано.
Прототип
Чорно-білий кістяк сторінки без кольорів і картинок.
Прототип відповідає на питання «що і в якому порядку стоїть на сторінці», доки не почалась суперечка про відтінок кнопки. Переставити блок тут коштує хвилини, а в готовому коді — дня. Саме тому прототип показують раніше за дизайн, хоч він і виглядає «непродано».
UX і UI
UX — чи зручно людині дійти до мети; UI — як це виглядає.
UX — про маршрут: скільки кроків до кошика, чи зрозуміло, що робити далі. UI — про вигляд: шрифти, відступи, кольори. Гарний UI поверх поганого UX дає красивий сайт, яким незручно користуватись, і це найдорожча з двох помилок.
Фавікон
Маленька іконка сайту на вкладці браузера й у закладках.
Дрібниця, яку помічають, коли її немає: без фавікона вкладка виглядає як чужа й губиться серед двадцяти інших. Окремо потрібна більша версія для iPhone — інакше «додати на екран» покаже сірий квадрат замість логотипа.
CMS (адмінка)
Панель, де ви самі міняєте тексти й картинки без програміста.
CMS потрібна там, де вміст живий: новини, каталог, ціни. Там, де сторінка міняється двічі на рік, вона додає роботи й місць для поломки — дешевше попросити правку. Важливе питання при виборі: що саме ви зможете міняти самі, а що все одно доведеться замовляти.

Домен, DNS і сертифікати

DNS
Телефонна книга інтернету: перекладає ім’я сайту в адресу сервера.
Комп’ютери спілкуються числами, люди — іменами; DNS перекладає одне в одне. Тому зміни тут не миттєві: попередню відповідь зберігають у себе провайдери й браузери, і на оновлення закладають від кількох хвилин до доби. Саме через це переїзд сайту планують, а не роблять о шостій вечора п’ятниці.
SSL-сертифікат і HTTPS
Замок у рядку адреси: шифрує дані між відвідувачем і сайтом.
Без сертифіката браузер малює попередження «не захищено», і половина відвідувачів іде ще до першого екрана. Сертифікат безкоштовний і оновлюється автоматично — але саме автоматика й ламається тихо: прострочений сертифікат кладе сайт цілком, хоч сам сайт справний.
Піддомен
Окремий розділ на тому самому домені: app.сайт.com.
Піддомен не потрібно купувати окремо — він створюється безкоштовно за хвилину. Його беруть, коли частина проєкту живе своїм життям: кабінет клієнта, блог на іншому рушії, тестова копія. Пошук здебільшого вважає піддомен окремим сайтом, тож переносити туди сторінки заради SEO — погана ідея.
CDN
Мережа серверів, що роздає копії сайту ближче до відвідувача.
Сайт фізично стоїть в одному місці, а відвідувачі — по всьому світу; CDN тримає його копії в десятках міст і віддає з найближчого. Це прискорює завантаження й заодно приймає на себе напади й сплески трафіку. Побічний ефект: помилки тепер треба шукати у двох місцях — на сервері й у CDN.
Редірект 301 і 302
Автоматичне перенаправлення зі старої адреси на нову.
301 означає «переїхали назавжди» — пошук переносить на нову адресу накопичену вагу старої. 302 означає «тимчасово» і ваги не передає. Переплутати їх під час переїзду сайту — класичний спосіб втратити позиції, які набирались роками.
Помилка 404
Сторінки за такою адресою немає.
404 — не поломка сайту, а чесна відповідь: адресу набрали з помилкою або сторінку прибрали. Погано, коли замість неї віддають порожній екран або, ще гірше, головну з кодом «усе гаразд»: тоді пошук роками тримає в індексі неіснуючі сторінки.

Як усе влаштовано зсередини

Фронтенд і бекенд
Фронтенд — те, що видно в браузері; бекенд — те, що рахує на сервері.
Кнопка, шрифт і анімація — фронтенд. Перевірка пароля, збереження заявки, підрахунок ціни — бекенд, і його не видно взагалі. Правки «підняти кнопку вище» й «додати поле в заявку» коштують по-різному саме тому, що живуть по різні боки цієї межі.
База даних
Місце, де сайт зберігає заявки, товари й користувачів.
Тексти сторінок можуть лежати у файлах, а от усе, що з’являється під час роботи — заявки, замовлення, повідомлення, — живе в базі. Її втрата болючіша за втрату коду: код можна написати заново, історію листування з клієнтом — ні. Тому в бази роблять резервні копії, і саме їх перевіряють на відновлення.
API
Спосіб для двох програм обмінюватись даними без людини посередині.
Коли сайт сам передає замовлення в 1С, тягне курс валют або надсилає лист через поштовий сервіс — це API. Для замовника важливе одне: якщо у вашої системи API є, зв’язок роблять за години; якщо немає — доводиться вигадувати обхід, і саме там ховається половина вартості інтеграції.
Git і репозиторій
Сховище коду з історією кожної зміни й можливістю відкотитись.
Кожна правка записана: видно, хто, коли й навіщо змінив рядок, і будь-який стан можна повернути. Для замовника з цього випливає практичне: код проєкту має лежати у ВАШОМУ репозиторії, а не в особистій теці підрядника — інакше зміна виконавця перетворюється на археологію.
Деплой (викочування)
Перенесення готових змін на живий сайт.
Правка, зроблена в коді, ще не стоїть на сайті: її треба викотити. Звідси частий подив «я ж бачив, що виправили, а на сайті старе» — виправили, але не викотили. Викочування роблять свідомо й у робочий час, щоб було кому подивитись, якщо щось піде не так.
Стейджинг (тестова копія)
Повна копія сайту, де перевіряють зміни до показу людям.
Виглядає й працює як бойовий сайт, але закритий від сторонніх і від пошуку. Саме тут ловлять поламану форму й з’їхану верстку. Показувати замовнику стейджинг — нормально; помилково прийняти його за живий сайт — теж буває, тому адресу підписують.
Резервна копія
Знімок сайту й бази, з якого можна відновитись після біди.
Копія, з якої жодного разу не відновлювались, — це не копія, а надія. Питання до будь-якого підрядника два: як часто робиться і коли востаннє перевіряли відновлення. Друге важливіше: саме там зазвичай і виявляється, що архіви порожні.
Кеш
Збережена копія сторінки, яку віддають замість того, щоб рахувати заново.
Кеш робить сайт швидким і він же — причина «я змінив, а нічого не змінилось». Стару копію може тримати браузер, CDN або сам сервер. Тому перевіряти правку треба з оновленням без кешу, а на живому сайті — після того, як кеш скинули свідомо.

Пошук і SEO

Індексація
Занесення сторінки до бази пошуковика — без цього її не знайдуть.
Спершу робот приходить і читає сторінку, потім вирішує, чи брати її в базу, і лише після цього вона може з’явитись у видачі. Між публікацією й появою в пошуку минають дні, іноді тижні — це нормально й не лікується грошима. Прискорити можна тільки одним: попросити переобхід у панелі вебмайстра.
robots.txt
Файл із правилами для роботів: куди можна, а куди не варто.
Лежить за адресою сайт.com/robots.txt і читається першим. Це прохання, а не замок: чемні роботи слухаються, зловмисні — ні, тож ховати там таємне безглуздо. Одна помилка в цьому файлі здатна прибрати з пошуку весь сайт, тому його перевіряють після кожного переїзду.
Карта сайту (sitemap)
Машинний список усіх сторінок, який віддають пошуковику.
Робот знайшов би сторінки й сам, ідучи за посиланнями, але карта прискорює це й показує те, на що всередині сайту посилань мало. Вона має оновлюватись сама: список, зроблений руками рік тому, обіцяє пошуковику сторінки, яких уже немає.
Title і description
Заголовок і опис, які людина бачить у результатах пошуку.
Це ваша вітрина у видачі: за ними вирішують, клікнути чи піти до сусіда. Кожна сторінка мусить мати свої; однакові на весь сайт — найпоширеніша помилка, після якої пошук сам вигадує заголовки замість вас. Description на позицію прямо не впливає, а от на кількість кліків — так.
Canonical
Позначка «ось головна версія цієї сторінки» для однакового вмісту.
Той самий товар часто доступний за кількома адресами — з фільтром, із міткою реклами, з www і без. Для пошуку це кілька однакових сторінок, між якими він ділить вагу. Canonical каже, яку вважати головною, і збирає вагу докупи.
hreflang
Зв’язка мовних версій однієї сторінки між собою.
Каже пошуку: ця сторінка — іврит, її двійник — українська, а ось англійська. Тоді ізраїльтянин бачить у видачі івритську, а не українську. Правило суворе: усі версії мусять посилатись одна на одну, інакше зв’язку не зараховують цілком.
Core Web Vitals
Три виміри швидкості й стабільності сторінки, які враховує Google.
Міряють, коли з’явився головний блок, чи швидко сторінка відповідає на дотик і чи не стрибає верстка під пальцем. Це не про красиві бали в тесті, а про людину з телефоном у метро. Найчастіші винуватці провалу — важкі картинки й чужі скрипти лічильників.
Структуровані дані
Прихована розмітка, що пояснює машині зміст сторінки.
Людина бачить «1 200 ₴» і розуміє, що це ціна; машині це треба сказати окремо. Завдяки такій розмітці у видачі з’являються зірочки відгуків, ціни й розгорнуті питання, а ШІ-асистенти точніше цитують сайт. Правило одне: розмітка мусить збігатися з видимим текстом, інакше це обман і за нього карають.

Аналітика

Google Analytics 4
Безкоштовний лічильник: скільки людей прийшло, звідки й що робили.
Ставиться одним рядком коду й починає рахувати з дня встановлення — заднім числом даних не буває, тому ставлять до запуску, а не після. Сам собою лічильник показує лише перегляди; щоб бачити заявки, події треба налаштувати окремо.
Подія
Зафіксована дія відвідувача: клік, відправлена форма, звантажений файл.
Перегляди сторінок рахуються самі, а от «людина надіслала заявку» — ні: це треба задати. Без цього аналітика чесно покаже трафік і нічого не скаже про сенс: сто відвідувачів на день можуть означати три заявки, а можуть нуль.
Конверсія
Частка відвідувачів, які зробили те, заради чого сайт існує.
Сто відвідувачів і дві заявки — конверсія 2%. Це головне число сайту: подвоїти його зазвичай дешевше, ніж подвоїти трафік. Порівнювати свою конверсію з чужою марно — надто різні ніші й джерела; порівнюють із собою місяць тому.
UTM-мітки
Хвостик в адресі, який каже аналітиці, звідки прийшла людина.
Без міток усі переходи з розсилки, реклами й повідомлення в месенджері зливаються в безлику купу. З мітками видно, який саме допис привів заявку. Мітки треба класти на посилання ДО запуску кампанії: додати їх заднім числом неможливо.

Пошта й листи

SPF, DKIM, DMARC
Три записи, які доводять, що лист із вашого домену справді ваш.
SPF перелічує, кому дозволено писати від вашого імені; DKIM ставить на лист підпис; DMARC каже, що робити з листом, який перевірку не пройшов. Без них листи або йдуть у спам, або будь-хто може писати від вашого імені. Налаштовуються один раз у DNS і живуть роками.
Транзакційний лист
Лист у відповідь на дію: підтвердження замовлення, код входу, рахунок.
Його чекають, тому він мусить прийти за секунди й не в спам. Такі листи шлють через спеціальний сервіс, а не з поштової скриньки на хостингу: у сервісу є репутація відправника, історія доставки й видно, що саме сталося з кожним листом.
Доставність
Чи доходять ваші листи до «Вхідних», а не до спаму.
Найпідступніше тут те, що поштовий сервер відповідає «прийнято» й у тому разі, коли лист потім тихо кладуть у спам або відкидають. Тому доставність перевіряють не за кодом відповіді, а за реальною скринькою: надіслали — відкрили — побачили.

Гроші, строки, процес

Технічне завдання (ТЗ)
Список того, що буде зроблено, — і мовчазно того, чого не буде.
ТЗ — це не бюрократія, а межа: усе, чого в ньому немає, робиться за окрему домовленість. Саме тому ціна фіксується разом із ним, а не «на око» до нього. Читати ТЗ варто прискіпливо: питання «а це входить?» дешеве до підпису й дороге після.
Кошторис і вилка ціни
Попередній розрахунок «від і до» на підставі відомого зараз.
Вилка — це чесність, а не ухиляння: доки не описані сторінки й інтеграції, точної цифри не існує ні в кого. Разом із вилкою мають іти припущення, на яких вона стоїть, — саме вони й пояснюють, чому ціна поїде вгору, якщо щось із них не справдиться.
Етап (віха)
Ділянка роботи з видимим результатом і своїм строком.
Проєкт ділять на етапи, щоб було видно рух, а не «щось робиться два місяці». Кожен етап закінчується тим, що можна подивитись очима: прототип, дизайн, робочий сайт на тестовій адресі. Оплата зазвичай прив’язана саме до них.
Реліз
Момент, коли зроблене стає доступним справжнім користувачам.
Перший реліз рідко буває «повним сайтом» — і це навмисно: краще запустити вузьку робочу версію й побачити живих людей, ніж півроку доробляти наосліп. Усе, що не увійшло, не зникає, а стає списком наступного релізу.
Підтримка
Робота після запуску: оновлення, дрібні правки, реакція на поломки.
Сайт не стоїть на місці й без вас: оновлюються браузери, протухають сертифікати, змінюються правила поштових служб. Підтримка — це не «а раптом зламається», а планове доглядання. Головне питання в договорі: за який час вам відповідають, коли лягло.

ШІ та автоматизація

Мовна модель (LLM)
Програма, що працює з текстом як людина: читає, пише, перекладає, підсумовує.
Це те, що стоїть за ChatGPT, Gemini й Claude. Для бізнесу важливе не «розумність», а межа: модель добре робить те, де є текст і правила, і погано — те, де потрібна відповідальність за наслідок. Тому її ставлять на чернетку, а не на останнє слово.
Промпт
Текстове завдання, яке дають моделі.
Якість відповіді залежить від завдання більше, ніж від моделі: та сама модель на розпливчасте прохання дає розпливчасту відповідь. У робочих системах промпт не пишуть щоразу заново — його налагоджують один раз і зберігають як частину коду.
ШІ-агент
Модель, якій дали інструменти й дозволили діяти, а не лише відповідати.
Агент може сам відкрити сторінку, прочитати файл, записати рядок у базу. Звідси й користь, і ризик: він робить кроки без питання. Тому в робочих системах агентові окреслюють, що йому дозволено, а незворотні дії лишають за людиною.
llms.txt
Файл-довідка про сайт, написана для мовних моделей.
Те саме, чим robots.txt є для пошукових роботів, тільки словами: коротко про те, що на сайті є, і посилання на головні сторінки. Модель, яку спитали «хто зробить сайт із кабінетом», читає його швидше, ніж п’ятдесят кілобайт розмітки, і точніше цитує.

Не знайшли слова, яке вам сказали? Напишіть його нам — додамо сюди й пояснимо вам особисто.