У користувачів часто виникають питання, що таке URL-адреса файлу (сайту), як дізнатися його і в чому цінність такого реквізиту. Наша стаття надасть необхідні відповіді.
Що таке URL
Uniform Resource Locator розшифровується як "покажчик місцезнаходження сайту в Мережі". URL-ідентифікатор складається з доменного імені та шляху до певної сторінки з назвою її файлу. Винахідником URL-адреси був член Європейської ради з ядерно-військових проблем, що засідає у Женеві, Тім Бернерс-Лі. На момент свого створення в 1990 році URL сайту - це просто адреса в системі, за якою знаходиться файл. Щоб дізнатись URL сайту, достатньо заглянути в адресний рядок, а для визначення адреси файлу необхідно перейти в контекстне меню, натиснувши на відповідному об'єкті праву кнопку миші. Маючи безліч переваг, зокрема доступність навігації в Мережі, така адреса має і недолік - здатність працювати виключно з латиницею, деякими символами та цифрами. За необхідності використання кирилиці проводиться спеціальне перекодування.
Різновиди URL
Статичний – не передбачає змін на сторінці.
Динамічний URL - що це, можна зрозуміти, якщо уявити пошукову форму або інший навігаційний інструмент, В якому інформація генерується в залежності від запитів, що надходять.
Адреса з ідентифікатором сесій, який додається щоразу, коли користувачі відвідують сторінку.
Значення URL у SEO-просуванні
Пошуковики враховують ключі, що входять до URL-адреси. Найбільше впливають на пошукове просування ключові словав домені та піддоменах.
Якщо адреса сайту інформативна, це також підвищує рейтинг. Пошуковий робот із великою ймовірністю видасть його у відповідь на тематичний запит.
URL, що відповідає запиту, виділяється у пошуковій видачі жирним шрифтом, привертаючи додаткову увагу та підвищуючи клікабельність.
Заблукати можна не тільки в лісі, але і в онлайні. І тому виною може стати неправильний шлях або адреса, що веде до ресурсу. Ви не знаєте, що таке URL-адреса? Тоді перш, ніж пускатися в подальшу подорож віртуальним простором, давайте розберемося із системою електронних адрес.
Що таке URL
URL є загальноприйнятим стандартом запису адреси та вказівки на розміщення ресурсу в Інтернеті. З англійської його назва ( Uniform Resource Locator) перекладається як єдиний покажчик ресурсів. Можна зустріти більш раннє розшифрування абревіатури URL - Universal Resource Locator (універсальний локатор ресурсів). Але обидва значення швидше доповнюють поняття URL, ніж перечать один одному.
Основний формат запису структури URL-адреси виглядає так:
://:@:/?#
- Найчастіше мається на увазі протокол.
логін - логін користувача, що використовується для авторизації на ресурсі.
пароль – пароль користувача для авторизації.
хост – доменне ім'я хоста.
порт – порт хоста, який використовується під час підключення.
URL – шлях, яким знаходиться запитуваний ресурс на сервері.
параметри та якір– значення змінних та ідентифікатор на певному ресурсі.
Передача значення змінних у рядку запиту можливе лише за допомогою методу GET.
Розглянемо формат URL адреси сторінки запитуваного ресурсу на прикладах. На стороні клієнта URL відображається в адресному рядку браузера:
Найчастіше зустрічаються такі варіанти:
- http:// ru.wikipedia.org/wiki/Заголовна_сторінка– для надсилання запиту використовується http ( протокол передачі гіпертексту);
- https://ua.wikipedia.org/wiki/Заголовна_сторінка- Як спосіб передачі використовується https . Є захищеною формою протоколу http, що використовує шифрування (SSL або TLS);
- fttp://wikipedia.org/wiki/file.txt- Протокол передачі файлів fttp;
- http://mail.ru/script.php?num=10&type=new&v=text– передача значень змінних у рядку запиту за допомогою методу GET.
Будь-який формат URL адреси є, перш за все, символьним рядком. До її складу можуть входити:
2; Латинські літери.
2; Арабські цифри (0-9).
2; Зарезервовані символи ("+", "=", "!" та інші).
2; Спеціальні символи – на них зупинимося докладніше.
Використання спеціальних символів в URL
Звичайно, таких занадто «спеціальних» символів в URL не використовують. Але дещо є:
- ? - служить для відділення в рядку запиту блоку з параметрами, що передаються;
- & — відокремлює параметри, що передаються один від одного;
- = - Відокремлює в параметрі змінну від її значення;
- : — служить відділення протоколу від решти URL;
- # — Символ використовується в локальній частині адреси. Дозволяє звернутися до певної частини запитуваної сторінки;
- @ — вказується в реєстраційних даних користувача та при передачі даних за допомогою протоколу mailto.
Але це лише теорія. Тому перед тим, як дізнатися про інше, розглянемо невеликий практичний приклад.
Наочний приклад
Візьмемо для наочності таку просту форму реєстрації:
Ось її код:
Форма регістрації
Першим рядком на початку форми ми прописали для неї файл обробника (php) та метод передачі даних через URL адресу сервера:
Тепер наведемо код файлу обробника (1.php):
Ваш Нік:".$_GET["nick"]."
"; echo" Ваш вік:".$_GET["age"]."
";
?>
Введемо дані у форму та відправимо їх для обробки на сервер. Ось що ми отримаємо у результаті:
Зверніть увагу на формат URL у адресному рядку на першому скріншоті. Після введення даних та натискання на кнопку «Надсилання даних» значення всіх полів відправляються для обробки на сервер. А нас перенаправляє на сторінку 1.php, де розміщено код обробника.
Перш ніж подивитися на результат обробки, погляньте на адресний рядок на другому малюнку. У ній відображаються значення полів, переданих на обробку методом GET.
Щоб приховати дані, що надсилаються на сервер, використовується метод POST. Тоді наведений вище URL буде виглядати так:
http://localhost/home/1.php.
Формат URL-адрес на сайтах
Найчастіше на сайтах використовується деревоподібна система URL. Тобто правильна URL-адреса складається з декількох вкладених один в одного елементів, останній з яких і є потрібною веб-сторінкою.
Для наочності візьмемо конкретний URL , що є одним із розгалужень адреси нашого сайту:
https://www..html
Розберемо його частинами:
- www.сайт – це частина є доменним ім'ям сайту. Якщо набрати його в адресному рядку браузера, воно виведе на головну сторінку сайту. Найчастіше це файл index. html;
- templates – дана частина адреси вказує на певний розділсайту. У нашому випадку це розділ із шаблонами;
- page_2.html – це кінцевий елемент URL , що веде на веб-сторінку тематичного розділу ресурсу.
Найчастіше URL-адреси основних розділів повністю відображають карту сайту. Але не все так просто з переадресацією на сайтах, розгорнутих на основі популярних двигунів (CMS).
Особливості побудови URL у WordPress
У WordPress, як і в будь-якому движку, побудованому на php, генерація всіх сторінок сайту відбувається динамічно. Тобто одна частина береться з одного шаблону, інша генерується «на льоту» на основі декількох. Але така летючість має один істотний недолік - наявність шматків параметрів, що передаються в URL .
Причому це обмежує не лише естетичну складову відображення адрес, але й неоднозначно сприймається пошуковими системами. А це може негативно впливати на просування сайту:
Тому краще використовувати на своєму сайті чисті URL-адреси. Але де взяти їх, якщо CMS система не передбачає можливості їхнього редагування.
Чисті URL - це адреси, що не містять переданих параметрів (у випадку з WordPress - елементів запитів до бази даних), а лише шлях до документа. Тобто https://www..html є прикладом чистої URL-адреси.
Найпростіший спосіб налаштування відображення URL у WordPress – це використання спеціалізованих плагінів.
: завжди хотів це зрозуміти, але значимість його була настільки мала, що завжди був привід цього не робити:)
А ви запитували: URL - що це?
Завжди з таким стикаюся, але досі не бажав зрозуміти у чому різниця між термінами URI, URL, URN, а тут раптом постік (на жаль, він уже канув у Лету), вирішив - і сам почитаю, і іншим розповім, хоча, як сказано вище, від цього нічого не зміниться, але люблю я іноді побуквоєдувати, так що читайте тлумачний перекладець:
Ви колись звертали увагу на адресний рядок у Вашому браузері? Що це? URI, URL чи URN? Багато хто з нас не робить відмінностей між URI, URL, URN, а дехто навіть не чув термінів URI та URN, всі просто користуються терміном URL. Давайте разом спробуємо розібратися у цьому.
Розшифровка абревіатур
URI - Uniform Resource Identifier (уніфікований ідентифікаторресурсу)
URL - Uniform Resource Locator (уніфікований визначник місцезнаходженняресурсу)
URN - Unifrorm Resource Name (уніфіковане ім'яресурсу)
Увага, тут у дрібницях криється істина, але поки що нічого не зрозуміло, якась каша. Їдемо далі.
Визначення
URI: Позначає ім'я та адресу ресурсу мережі. Як правило, ділиться на URL та URN, тому URL та URN це складові URI.
URL: Адреса деякого ресурсу в Інтернеті. URL визначає місцезнаходження ресурсу та спосіб звернення до нього.
URN: Ім'я деякого ресурсу в Інтернеті. Сенс URN у тому, що він визначає лише назву конкретного предмета, який може знаходитись у безлічі конкретних місць.
Немає нічого кращого, ніж конкретний приклад
URI = http://сайт/2009/09/uri-url-urn.html
URL = http://сайт
URN = /2009/09/uri-url-urn.html
Підведемо підсумки
URI це концепція абстрактного ідентифікатора, тоді як URL та URN конкретна реалізація - адреси та імені.
Сподіваюся всім зрозуміло. Будьте грамотні!
Сприйняття кожного з нас індивідуальне, тому — сперечайтеся та читайте обговорення у коментарях до статті, там багато чого цікавого.
Суперечки з цього питання - як правильно писати URL, зі слідом на кінці чи без? - Були і будуть. Аргументація зустрічається різноманітна і часто суперечлива. А розплату за неправильний запис універсального локатора ресурсу (URL) уявляють двох видів. З боку пошукових систем - це нібито штрафні санкції за дублі сторінок. З погляду продуктивності - нібито зайвий редирект на сторінку правильного запису, що автоматично генерується сервером.
Однак, розбираючи технічні специфікації стандартів Інтернету, зокрема документ "RFC 1738 - Uniform Resource Locators (URL)", доводиться визнати, що обидва варіанти запису адреси веб-ресурсу формально правильні, і санкція за використання того чи іншого варіанту - не більш ніж бзік пошукової системиабо байки псевдо-SEO-шників.
З позиції лаконічності, більш правильним є варіант без сліша на кінці незалежно від того, чи адресує ваше посилання "файл" на сервері або "папку", непрямий доказ чого буде продемонстровано нижче. Але немає жодного твердження у документі, що інший варіант неправильний чи посилається зовсім на інший ресурс.
Завантажувати вас багатосторінковим перекладом згаданого RFC не стану, оскільки, по-перше, метою питання були сліши на кінці URL, і по-друге, публікація адресована простим користувачам движків, в тому числі і , яким вся деталізація не цікава, вони чекають коротких роз'яснень та доказів по суті. Відповідно, я цитуватиму витримки з цього документа як доказову базу і пояснюю. Кому і це не цікаво, може одразу дивитися висновок наприкінці статті.
Загальний синтаксис URL
Насамперед приверну увагу до витримки з параграфа 2. General URL Syntax (загальний синтаксис URL). У кожному випадку наводитиму фрагмент тексту мовою оригіналу і потім переклад російською мовою.
URL-адреси, що використовуються для 'locate' ресурсів, дають змогу відображати абстрактне позначення ресурсу location.
Тобто сам URL – це чиста абстракція. Що він може здатися нам зовні схожим на ім'я файлу або папки, зовсім не означає фізичну вказівку на саме такий файл, а не якийсь інший у файловому просторі сервера. Нижче у документі про це буде заявлено прямо.
НотаткаВзагалі щодо http-посилань у принципі невірно говорити, що, наприклад,
- http://domain.com/path/subpath/filename.txt- нібито вказує на файл
- http://domain.com/path/subpath/- нібито вказує на папку
- http://domain.com/path - нібито неправильно вказує на папку
Ми просто звикли так казати, тому що зручно асоціювати посилання з файлами на сайті. Насправді всі ці посилання вказують деякі ресурси, жодним чином не позначаючи тип ресурсу. Що ж ховається за кожним ресурсом, тобто який реальний файл або папка і який тип контенту буде відданий за таким посиланням, то вже визначено конфігурацією сервера.
Важливо усвідомити, що у посиланнях немає такого поняття як "файл", "папка", "підпапка", "текст", "картинка", "html", "скрипт", "таблиця стилів" тощо. Ніякий сліш на кінці або його відсутність не означає зовсім нічого доти, поки посилання не пройде трансформацію всередині сервера, і вже він сам вирішить, куди ж насправді вказує посилання і який контент якого типу ховається за нею. Тільки це рішення стосується внутрішньої архітектури сервера.
Ієрархічні схеми
Далі витримка з параграфа 2.3 Hierarchical schemes and relative links (ієрархічні схеми та відносні посилання).
Деякі URL schemes (так як ftp, http, і файли schemes) contain names that can be considered hierarchical; components of hierarchy є окремо від "/". Деякі схеми URL (такі як ftp, http та file) містять імена, які можна вважати ієрархічними; елементи ієрархії розділені символом "/".
Тобто стверджується, що в окремих схемах адрес вміст локатора ресурсу не заборонено мати на увазі ієрархічним, причому поки не обговорювалося, що ієрархія еквівалентна будь-якій формі, скажімо файлової.
Загальний синтаксис мережної схеми
Далі витяг із параграфа 3.1. Common Internet Scheme Syntax (загальний синтаксис мережної схеми).
//:@:/Один або всі частини " :@", ":",
":", and "/ " may be excluded. Деякі або всі частини " :@", ":",
":" і "/ можна виключати.
НотаткаЦе, до речі, у відповідь питання, похідний від аналізованого нами. Нерідко і з такого питання сперечаються: як правильно давати посилання на домен (хост) - без сліша в кінці або зі слішем?
Як правильно http://domain.com/ або http://domain.com?
І так і так вірно. Просто перший сліш після імені хоста призначений для відокремлення імені шляху від імені хоста. Той самий параграф документа повідомляє про це так:
Url-path Зовнішнє місцезнаходження вмісту даних, специфічних для scheme, і є відомим як "url-path". Це вказує на те, як особливий ресурс може бути використаний. Зауважте, що "/" між host (або порт) і url-path не є частиною url-path. Інша частина локатора складається з даних, притаманних схеми, і відома як "url-path" (шлях URL). Вона повідомляє подробиці, як можна отримати доступ до зазначеного ресурсу. Зверніть увагу, що символ "/" між хостом (або портом) і шляхом URL - це частина url-path.
Ні словом не зобов'язали вас ставити цей замикаючий символ або не ставити, коли url-path дорівнює порожньому рядку (як сказали багато хто з нас, коли URL посилається в корінь сайту). Ніхто не має права застосувати до вас штрафні санкції "за два дублі головної сторінки", бо згідно зі специфікацією, в обох випадках ви посилаєте URL на той самий ресурс.
Продовжимоще однією витримкою із того ж параграфа.
url-path syntax depends on scheme being used, as does the manner в which it is interpreted. Синтаксис url-path залежить від схеми, як і спосіб, яким він інтерпретується.
Це надмірне підтвердження, що з кожної схеми локатора своє поняття " ієрархії " і спосіб її інтерпретації.
Ієрархія
Для кількох системних файлів, "/" використовувалися для позначення hierarchical structure of URL corresponds to delimiter used to construct a file name hierarchy, and thus, filename will look similar to the URL path. Це не так, що URL-адреса є Unix filename. Символ "/" використаний для позначення ієрархічної структури URL відповідно до роздільника, який використовується в конструюванні ієрархії файлових імен, і таким чином у деяких файлових системах ім'я файлу виглядає подібним до шляху URL. Але це не означає, що URL - це Unix-подібне ім'я файлу. Незважаючи на те, що цей параграф відноситься до схеми ftp, проте його затвердження поширені й на інші схеми (http, gopher, prospero тощо). Лише у схемі file символ слеша логічно позначає те саме, що і в іменах файлів, наприклад file://server_or_device/path/subpath/filename.txt.
Http
An HTTP URL така форма: http:// :/?where and Are as described in Section 3.1. If: Це заміщено, порти до 80. Не використовується username або password is allowed. Is an HTTP selector, and is a query string. The Is optional, as is the and its preceding "?". If neither Nor is present, the "/" may also be omitted. Within the And components, "/", ";", "?" are reserved. Цей "/" характер може бути використаний зв HTTP для створення ієрархічної структури. URL схеми http набуває форми: http:// :/?де і Такі ж, як описані в параграфі 3.1. Якщо: Опущено, що порт за замовчуванням вважається рівним 80. Ім'я користувача або пароль неприпустимі. Це селектор HTTP, і - Рядок запиту. Є опціональним, як і разом із попереднім йому символом "?". Якщо не Ні відсутні, символ "/" може бути опущений. В елементах І символи "/", ";", "?" є зарезервованими. Символ "/" може використовуватися в HTTP для визначення ієрархічної структури.
НотаткаТут також стверджується, що можна вказувати посилання без кінцевого сліша. У разі йшлося про ситуацію, коли шлях посилання порожній - вказує на корінь хоста.
Формальний запис
І, нарешті, витримка з параграфа 5. BNF for specific URL schemes (формальний запис для конкретних схем URL).
Тут у квадратних дужках вказано опціональні частини. Зірочка перед дужкою позначає 0 або більше повторів такого фрагмента, як зазначено у дужках. Вертикальну межу слід розуміти як АБО.
Hostport = host [ ":" port ] ... ... httpurl = "http://" hostport [ "/" hpath [ "?" search ]] hpath= hsegment * [ "/" hsegment ] hsegment = * [uchar | ";" | ":" | "@" | "&" | "="] search = * [uchar | ";" | ":" | "@" | "&" | "="] ... ... lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "T" | "u" | "v" | "w" | "х" | "y" | "z" hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "І" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" alpha = lowalpha | hialpha digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" safe = "$" | "-" | "_" | "." | "+" extra = "!" | "*" | """ | "(" | ")" | "," hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" "c" | "d" | "e" | "f" escape = "%" hex hex unreserved = alpha | digit | safe |
Зверніть увагу, як точно за правилами формується елемент hpath – шлях посилання. Елементи hsegment шляху - сегменти - поділяються слішем. Наче натякаючи на важливу ідею, що сліш ділить шлях на ієрархічні частини і завжди знаходиться всередині. В принципі не виключається, що останній елемент hsegment може бути порожнім рядком (це випливає з його визначення), і тоді на кінці URL мимоволі з'являється закриває сліш.
Висновок
Поділ шляху на сегменти за допомогою символу слеша має на увазі наявність непустих імен цих сегментів. Відповідно, посилання зі слешем на кінці бачиться нелогічним (хоча і не заборонено) у тому сенсі, що вона начебто вказує на якийсь останній сегмент шляху, але притому ніяк не називає цей сегмент. Так як нелогічне (але теж не заборонене) посилання http://domain.com/level1/////levelXне називає проміжні сегменти шляху, якщо шлях розглядати не як набір параметрів, а як ієрархічну структуру.
Просторовою мовою смислове наповнення двох посилань можна пояснити так:
- - адресує дефолтну початкову точку другого рівня ієрархії
- - адресує в невизначену точку всередині другого рівня ієрархії, тобто на сервер покладають завдання, що "ми звертаємося до другого рівня ієрархії, а ти сам визнач, яку точку вважаєш у цьому рівні дефолтної початкової".
З усього сказаного вище випливає, що аналогічно тому, як посилання
- http://domain.com
- http://domain.com/
адресують відвідувача в корінь сайту, так і, наприклад, посилання
- http://domain.com/level1/level2
- http://domain.com/level1/level2/
адресують відвідувача на другий рівень ієрархії ресурсу. А те, що якийсь сервер може інтерпретувати сліш на кінці по-своєму і почати внутрішньо редиректити на дефолтну початкову точку рівня - скажімо на файл index.html, це вже окремий випадок конкретної конфігурації. Так як і в реалізації системи людино-зрозумілих URL всі записи редиректів за допомогою серверного модуля mod_rewrite визначають своє (притаманне конкретному движку) поняття ієрархічної будови URL, в якому елементи шляху можуть прирівнюватися до параметрів запиту і не мати спільного з файловою структурою сайту ( класичний приклад: http://domain.com/ru/path , елемент ru – це параметр поточної мови, а не папка на сайті).
Особливо підкреслю, що це внутрішні знання сервера, зумовлені його конфігурацією, а також встановленим на сайті двигуном. Зовнішній сервіс, скажімо той же пошуковик, домислів робити не може і поняття не має, чи відрізняються і чим посилання зі слідом і без, якщо тільки сервер сайту спеціально не налаштували так, щоб за такими посиланнями видавати різний контент.
До відома
На рівні реалізації питання слешей на кінцях не має принципового значення, чому безліч підтверджень серед іменитих порталів. На одних усі посилання завершують слішем, на інших - без слєшу. Головне щоб контент за посиланнями не виявлявся різним, і ще для Яндекса потрібно прописати 301-й редирект з тих посилань, якими ви не користуєтеся (скажімо, що закінчуються слідом), на ті, якими користуєтеся. Справа в тому, що за непідтвердженими твердженнями служби підтримки Яндекса, ця пошукова система нібито може помилятися і не "склеювати" (запам'ятовувати у своїх знаннях) або з деяким запізненням склеювати сліш-без-слішові адреси в одну.
Ось приклад реалізації такого редиректу за допомогою кореневого файлу .htaccess:
# якщо вхідний url закінчується слєш(ем, амі), # задаємо 301-й редирект на сторінку без слєша RewriteCond %(REQUEST_URI) ^/.+/$ RewriteRule ^(.*?)/+$ http://%(HTTP_HOST )/$1
Гуглу (знову ж таки за даними , не підтвердженим експериментом) ці редиректи не важливі, оскільки він ніби вміє склеювати такі адреси правильно і без редиректів.
Пам'ятайтеЄ чимало людей, які вважають себе SEO-фахівцями. Але не кожен із них таким є. Більше того, темою SEO часто спекулюють без належних знань та підстав, просто в розрахунку на те, що і ви не обізнані в цій галузі, тому легко повірите у будь-яку "локшину". Коли вам кажуть, що якась ваша сторінка "вилетіла з індексу", скористайтеся дуже гарною рекомендацією Яндекса: Дізнаватись про помилки індексування, якщо такі виникають, можна в сервісі Яндекс.Вебмастер. У цьому сервісі завжди можна побачити список ваших сторінок, які знаходяться в пошуку та список сторінок, які з якоїсь причини виключені з пошуку. Схожий сервіс є і Гугла. Довіряйте цим знанням, а не думці псевдо-спеціалістів, які щось краєм вуха чули, і на тій підставі рекомендують вам робити так, як їм здається єдино правильним.
ОсьДуже цікава публікаціяМаловідомі факти SEO, що вийшла у квітні 2017 року. Там представлено велике дослідження з безліччю скріншотів, яке починалося з метою перевірити справедливість кількох популярних суджень у галузі пошукового просування та на зрозумілих прикладах донести результати до звичайного власника сайту. Те ж дослідження принагідно демонструє молодому читачеві ряд очевидних, звичайних, і швидше навіть непримітних, але все ж таки дивовижних особливостей органічної видачі в пошуках Google і Yandex.
ОсьХоча наступне посилання майже не стосується SEO, все ж таки стане привабливим для seo-майстрів, що знаходяться зараз у пошуку додаткових замовлень. Під посиланням розміщено комерційну пропозицію, хлопці знайшли цікавий спосіб використання сайту. Приватному бізнесу пропонують створення рекламного щита онлайн на основі якоїсь спеціальної теми, під керуванням якої сайт, а точніше його перший екран виглядає неначе банерна розтяжка на білбордах зовнішньої реклами. На смартфоні повернув екран, розтяжка стала вертикальною та займає всю площу екрану, повернув назад, стала горизонтальною та знову на весь екран. А під першим екраном є текстовий придаток, куди користувачі зазвичай не скролять, але пошуковик добре бачить цей текст. Так ось найшвидші буратини регіонального бізнесу купують собі ці недорогі онлайн білборди як вигідну альтернативу контекстній рекламі та контекстно-медійній мережі Яндекса та Гугла. А щоб максимально тусуватися в місцевому пошуковому індексі, на просування свого щита готові стегнути грошей відразу на купу seo-текстів, що пахне некислою сумою. Судячи з чуток, замовлення на 30 кілорублів проскакують, і тому що хлопці аутсорсять їх партнерам сеошникам, тут можна навести мости партнерства і отримувати хороший доробок.
За різними даними від 50 до 95% всіх електронних листів у світі – спам від кібершахраїв. Цілі розсилки таких листів прості: заразити комп'ютер одержувача вірусом, вкрасти паролі користувача, змусити людину перевести гроші «на благодійність», ввести дані своєї банківської карткиабо надіслати скани документів.
Часто спам напружує з першого погляду: крива верстка, автоматично перекладений текст, форми для введення пароля у темі листа. Але бувають шкідливі листи, які виглядають пристойно, тонко грають на емоціях людини і не викликають сумнівів у їх правдивості.
У статті буде розказано про 4 типи шахрайських листів, на які найчастіше ведуться росіяни.
1. Листи від «державних організацій»
Шахраї можуть прикидатися податковою, Пенсійним фондом, Росспоживнаглядом, санепідемстанцією та іншими держорганізаціями. Для переконливості до листа вставляють водяні знаки, скани печаток та державну символіку. Найчастіше завдання злочинців - налякати людину і переконати її відкрити файл із вірусом у вкладенні.
Зазвичай це шифрувальник або блокатор вінди, який виводить комп'ютер із ладу та вимагає надіслати платне SMS для відновлення роботи. Шкідливий файл може маскуватися під судову ухвалу або повістку про виклик до начальника організації.
Страх та цікавість відключають свідомість користувача. На форумах бухгалтерів описані випадки, коли співробітники організацій приносили файли з вірусами на свої домашні комп'ютери, тому що не могли відкрити їх в офісі через антивірус.
Іноді шахраї просять надіслати у відповідь на лист документи, щоб зібрати відомості про фірму, які стануть у нагоді для інших схем обману. Минулого року одна група шахраїв змогла обдурити безліч людей, використавши прийом відволікання уваги «прохання надіслати папери факсом».
Коли бухгалтер чи менеджер читав це, він одразу проклинав податкову «Ось мамонти там сидять, е-моє!» і перемикав свої думки із самого листа на рішення технічних проблемз відправкою.
2. Листи від "банків"
Блокатори вінди та шифрувальники можуть ховатися у фальшивих листах не лише від держорганізацій, а й від банків. Повідомлення «На Ваше ім'я взяли кредит, ознайомтеся із судовим позовом» дійсно можуть налякати та викликати величезне бажання відкрити файл.
Також людину можуть переконати увійти до фальшивої особистий кабінет, пропонуючи подивитися нараховані бонуси або отримати приз, який він виграв у Лотереї Ощадбанку.
Рідше шахраї відправляють рахунки для оплати сервісних зборів та додаткових відсотків за кредитом, на 50-200 рублів, які простіше заплатити, ніж розумітися.
3. Листи від «колег»/«партнерів»
Деякі люди отримують десятки ділових листів із документами протягом робочого дня. З таким навантаженням можна легко повестися на мітку «Re:» у темі листа і забути про те, що з цією людиною ви поки що не переписувались.
Особливо, якщо в полі отруйник зазначено «Олександр Іванов», «Катерина Смирнова» або будь-яке просте російське ім'я, які абсолютно не затримуються в пам'яті людини, яка постійно працює з людьми.
Якщо метою шахраїв є не збір SMS-платежів за розблокування вінди, а заподіяння шкоди конкретної компанії, листи з вірусами та фішинговими посиланнями можуть розсилати від імені реальних працівників. Список співробітників можна зібрати в соцмережах або переглянути на сайті компанії.
Якщо людина бачить у ящику листа від людини із сусіднього відділу, то він до нього особливо не придивляється, може навіть проігнорувати попередження антивірусу і відкрити файл незважаючи ні на що.
4. Листи від "Google/Яндекс/Mail"
Google іноді надсилає листи власникам скриньок Gmail про те, що хтось намагався зайти у ваш обліковий запис або про те, що закінчилося місце на Google Drive. Шахраї успішно копіюють їх та змушують користувачів вводити паролі на підставних сайтах.
Фальшиві листи від адміністрації сервісу також отримують користувачі Яндекс.Пошти, Mail.ru та інших поштових служб. Стандартні легенди такі: ваша адреса додана в чорний список, термін дії пароля минув, всі листи з вашої адреси будуть додаватися в папку спам, подивіться список недоставлених листів. Як і в трьох попередніх пунктах, основними зброями злочинців є страх та цікавість користувачів.
Як захистити себе?
Встановіть антивірус на всі пристрої, щоб він автоматично блокував шкідливі файли. Якщо ви з якихось причин не хочете ним користуватися, то перевіряйте всі хоч трохи підозрілі поштові вкладення на virustotal.com
Ніколи не вводіть паролі вручну. Використовуйте менеджери паролів на всіх пристроях. Вони ніколи не запропонують вам варіант паролів для введення на підставних веб-сайтах. Якщо з якихось причин ви не хочете їх використовувати, то вручну набирайте URL-адресу сторінки, на якій збираєтеся вводити пароль. Це стосується всіх операційних систем.
Скрізь, де це можливо, підключіть підтвердження пароля по SMS або двофакторну ідентифікацію. І звичайно, варто пам'ятати про те, що незнайомим людям не можна надсилати скани документів, паспортні дані та переводити гроші.
Можливо багато читачів при погляді на скрини листів подумали: «Я що дурень файли з таких листів відкривати? За кілометр видно, що це є підстава. Я не буду паритися з менеджером паролів та двофакторною ідентифікацією. Я просто буду уважним».
Так, більшу частину шахрайських листів можна викрити на око. Але це не стосується випадків, коли атака спрямована безпосередньо на вас.
Найнебезпечніший спам - персональний
Якщо ревнива дружина захоче почитати пошту чоловіка, то Google запропонує їй десятки сайтів, які пропонують послугу «Зламування пошти та профілів у соцмережах без передоплати».
Схема їхньої роботи проста: вони надсилають людині якісні фішингові листи, які ретельно складені, акуратно зверстані та враховують особисті особливості людини. Такі шахраї щиро намагаються зачепити конкретну жертву. З'ясовують у замовника її коло спілкування, уподобання, слабкі місця. На розробку атаки на конкретну людину може піти година чи більше, але зусилля окупаються.
Якщо жертва трапляється, то надсилають замовнику скрін скриньки та просять сплатити (середня ціна близько $100) свої послуги. Після надходження грошей надсилають пароль від ящика або архів з усіма листами.
Часто буває, що коли людині надходить лист із посиланням на файл «Відео компромат на Таню Котову» (прихований кейлоггер) від свого брата, то наповнюється цікавістю. Якщо лист забезпечити текстом з подробицями, які відомі обмеженому колу осіб, то людина відразу заперечує можливість того, що брата могли зламати або їм прикидається хтось ще. Жертва розслабляється та відключає антивірус до чортової матері, щоб відкрити файл.
До подібних послуг можуть звертатися не лише ревниві дружини, а й несумлінні конкуренти. У таких випадках цінник вищий і методи тонші.
Не варто сподіватися на свою уважність та здоровий глузд. Нехай про всяк випадок вас страхують беземоційні антивірус та менеджер паролів.
P.S. Навіщо спамери пишуть такі «тупі» листи?
Ретельно підготовлені шахрайські листи – відносна рідкість. Якщо зайти в папку спам, можна повеселитися від душі. Яких тільки персонажів не вигадують шахраї для здирства грошей: директор ФБР, героїня серіалу «Гра Престолів», ясновидець, якого до вас направили вищі силиі він хоче розповісти таємницю вашого майбутнього за $15 доларів, кілер, якому вас замовили, але він душевно пропонує відкупитись.
Велика кількість знаків оклику, кнопки в тілі листа, дивна адреса відправника, безіменне вітання, автоматичний переклад, грубі помилкиу тексті, явний перебір креативності – листи в папці спам просто «кричать» про своє темне походження.
Чому шахраї, які розсилають свої послання мільйонам адресатів, не хочуть витратити кілька годин на складання акуратного листа і шкодують 20 доларів на перекладача, щоб збільшити відгук аудиторії?
У дослідженні Microsoft Why do Nigerian Scammers Say They are from Nigeria?глибоко аналізується питання «Чому шахраї продовжують надсилати листи від імені мільярдерів з Нігерії, коли про «нігерійські листи» широкому загалу відомо вже років 20». За статистикою, понад 99,99% одержувачів ігнорує такий спам.
