Вспомнил, как раньше открывал Yahoo и тыкал по названиям каталогов. Потом был AltaVista, Rambler, ранний Яндекс — и каждый раз поиск становился лучше, но от идеала был далёк.
В 2025 у нас есть Perplexity, Google Gemini и куча ИИ-инструментов, которые сами пишут ответы вместо списка ссылок. Я долго копался в этой теме, а потом собрал фишки и приёмы поиска, которые экономят часы на ресёрче, в этой статье.
Ну, и немножко истории.
Оглавление
Сначала про Yahoo: Каталог как цифровая телефонная книга
Олды здесь, а значит и про Yahoo помните. Его создали в 1994 году Джерри Янг и Дэвид Фило. И изначально он был не поисковиком, а каталогом — структурированным списком сайтов, сделанным вручную.
Пользователь заходил на главную страницу сайта, выбирал нужную ему категорию, затем подкатегорию и (если повезёт) находил нужный сайт через несколько (иногда десятков) кликов.
Если говорить техническим языком, то Yahoo был базой данных в виде иерархического дерева. Каждая категория — узел, связанный с подкатегориями и конечными записями — ссылками на сайты с краткими аннотациями.
Сама база хранилась на серверах, а интерфейс работал через HTML-страницы с гиперссылками. Человек взаимодействовал с каталогом через браузер, кликая по категориям, которые загружались как статические страницы.
Я написал эту статью специально для блога Minervasoft. Компания помогает среднему и крупному бизнесу эффективно внедрять GenAI: объединяет все корпоративные знания в одном источнике — системе управления знаниями Minerva Knowledge — и с помощью авторской методологии делает так, чтобы статьи всегда оставались актуальными, структурированными и понятными. Это снижает риск галлюцинаций и повышает корректность ответов ИИ-агента до 94%.
Поиск в Yahoo был до ужаса простым в самом начале: он использовал совпадение ключевых слов в названиях сайтов или их описаниях, без анализа того, что было на самих страницах.
Обработка запросов Yahoo происходила по булевской модели: если юзер вводил слово "компьютеры", система искала точные совпадения в аннотациях или заголовках категорий.
Система держалась аж до 1998 года, но потом объёмы интернета выросли до десятков миллионов страниц. Модерировать вручную столько запросов, сами понимаете, невозможно. Редакторы перестали успевать классифицировать новые сайты, и каталог канул в лету.
Ещё был AltaVista — динозавр автоматизированного поиска
AltaVista, запущенная в 1995 году компанией Digital Equipment Corporation, был похож на настоящий поисковик. Ребята, работающие в компании, первыми отказались от ручной сортировки в пользу автоматизации.
В отличие от Yahoo, AltaVista использовала краулеры — программы, которые автоматически "ползали" по сайтам, собирали их содержимое и создавали базу данных. Юзер вводил запрос, и система искала совпадения по ключевым словам.
Процесс выглядел так:
Краулинг: Краулер AltaVista (называемый Scooter) сканировал веб-страницы, переходя по ссылкам. Он извлекал текст, заголовки, метатеги и анкоры ссылок, сохраняя их в базе данных. К 1997 году индекс AltaVista содержал около 30 миллионов страниц — огромный объём для того времени.
Индексация: Текст страниц разбивался на слова (токенизация), и создавался инвертированный индекс. Например, слово "computer" связывалось со списком всех страниц, где оно встречалось, с указанием позиций и частоты. Для ускорения индексации использовались хэш-таблицы, а данные хранились на серверах DEC Alpha, довольно мощных для 90-х.
Обработка запроса: Пользовательский запрос токенизировался, и система искала совпадения в индексе, используя булевскую модель поиска (AND, OR, NOT). Например, запрос "computer science" разбивался на ["computer", "science"], и система искала страницы, содержащие оба слова, с приоритетом на их близость (например, в пределах 10 слов) и частоту в заголовках или метатегах.
Ранжирование: AltaVista использовала раннюю версию TF-IDF (Term Frequency-Inverse Document Frequency) для ранжирования. TF считала частоту слов в документе (нормализованную на длину документа), а IDF снижала важность распространённых слов, таких как "and" или "the". Важность документа: ( TF-IDF(t, d) = TF(t, d) \cdot \log(N / df(t)) ), где ( TF(t, d) ) — частота термина ( t ) в документе ( d ), ( N ) — число документов, ( df(t) ) — число документов с термином ( t ). Допом учитывались заголовки и анкоры ссылок, которые получали повышенная важность.
Пример: для запроса "computer science" AltaVista находил страницы, где оба слова встречались чаще и ближе друг к другу, отдавая приоритет заголовкам. Но релевантность хромала: алгоритмы не учитывали контекст, поэтому запрос "Apple" мог выдать страницы о фруктах и компьютерах, а система не понимала разницы между "Apple" и "apple". Кроме того, AltaVista не оценивала авторитетность страниц, как Google позже сделал с PageRank, что приводило к случайным или низкокачественным результатам.
Но его алгоритмы всё равно оставались примитивными из-за:
отсутствия семантического анализа;
слабой защиты от спама — например, страницы, перегруженные ключевыми словами, снижали качество выдачи.
Зарождение рунета: Rambler и ранний Yandex
В середине 90-х интернет в России выглядел как современный “темщик”: сайтов — мало, соединение — медленное или никакое, но амбиций и желания сделать что-то своё — величиной с небоскрёб.
Рамблер появился в далёком 1996 году, и изначально был не поисковиком, а счётчиком посещений — что-то вроде примитивной аналитики для сайтов. Но уже через год команда поняла, что рунет растёт и пользователям нужно что-то помощнее.
Тогда Рамблер стал превращаться в поисковик с каталогом, похожим на Yahoo, но с упором на русскоязычные ресурсы. В 1997 году, когда в рунете было всего несколько тысяч сайтов, Рамблер стал любимчиком: его простой интерфейс и каталог, где сайты сортировались по темам, зашли большинству пользователей.
Если говорить о раннем Яндексе, то он появился ещё в 1997 году на выставке Softool, спустя год после Rambler.
Аркадий Волож и Илья Сегалович (основатели) понимали, что русский язык — штука сложная. Поэтому в основе поиска Яндекса лёг морфологический анализатор — программа, которая разбирала слово на части (корень, приставку, суффикс, окончание) и приводила его к «основе» — лемме.
Например, пользователь писал «книги», а система понимала:
корень — «книг»,
окончание «-и» = множественное число, родительный падеж,
лемма — «книга».
Дальше поиск охватывал все формы этого слова: «книга», «книге», «книгами» и т.д. Так поисковик «сглаживал» все варианты в одну базовую форму, что сильно повышало точность.
Yandex работал так:
Для хранения данных использовался инвертированный индекс: слева слово в нормализованной форме, справа — список документов, где оно встречается, плюс позиции внутри текста. Поэтому Яндекс быстро находил страницы по ключевым словам.
Чтобы наполнить этот индекс, краулер ходил по сайтам, собирал тексты, прогонял их через морфологический анализатор и сохранял результат в базе. Уже к 1998 году у Яндекса было несколько сотен тысяч страниц, и его поиск был сильно круче, чем у конкурентов — потому что там учитывалось много факторов:
не только частота слов, но и их порядок и расположение в тексте;
проверка, находятся ли слова рядом (phrase matching, обычно в пределах 5–10 слов);
булевская логика: «новости Москва» интерпретировалось как «новость» И «Москва» (с учётом всех падежей и форм). Для синонимов использовался OR.
Финальный рейтинг строился на основе доработанного алгоритма TF-IDF:
TF — сколько раз слово встречается в тексте (с поправкой на длину документа, чтобы большие статьи не выигрывали только за счёт размера).
IDF — насколько редким или уникальным было слово по сравнению со всей базой.
TF-IDF (Term Frequency-Inverse Document Frequency) — классический алгоритм информационного поиска, но с доработками для русского. TF (частота термина) рассчитывалась как количество нахождений леммы в документе, нормализованное на длину текста (чтобы не отдавать предпочтение длинным страницам):
TF(t, d) = f(t, d) / |d|
где f(t, d) — частота термина t в документе d, |d| — длина d. IDF (обратная частота документов) учитывала редкость слова в корпусе: IDF(t) = log(N / df(t)), где N — общее число документов, df(t) — число документов с t.
Итоговая важность: TF-IDF(t, d) = TF(t, d) * IDF(t).
На картинке: термин — слово, которое мы ищем; документ — текст, в котором встречается термин; TF (Term Frequency) — сколько раз слово встречается в документе; IDF (Inverse Document Frequency) — насколько редким это слово является среди всех документов; TF-IDF — произведение TF и IDF; ранжирование — документы сортируются по важности TF-IDF, чтобы показать самые релевантные в верхней части списка.
Ещё сильные опции поиска Яндекса:
Учитывалось, насколько близко слова из запроса расположены друг к другу. Если они рядом — документ считался более релевантным, и его важность увеличивалась (в полтора-два раза).
В рейтинг встраивался контекст — слова в заголовках, ссылках и других важных позициях имели большее значение.
Работа с синонимами и исправление опечаток. Для исправлений использовался принцип расстояния Левенштейна — метрика, которая показывает, сколько изменений нужно, чтобы превратить одно слово в другое.
Синонимы же находились с помощью тезауруса, который строили на основе больших корпусов текстов (позже — и Национального корпуса русского языка, в создании которого участвовал Илья Сегалович). Так поиск понимал, что «автомобиль» и «машина» — это одно и то же.
Например, для того же слова "машина" система вычисляла расстояние до слов в словаре: до "машина" — 1 (замена "а" на "ы"), и предлагала коррекцию, если расстояние ≤ 1-2. Это реализовывалось динамическим программированием:
матрица dp[i][j] = min(dp[i-1][j] + 1, dp[i][j-1] + 1, dp[i-1][j-1] + cost)
где cost = 0, если символы равны, иначе 1 через тезаурус на основе собранных корпусов текстов, а позже — и ресурсов вроде НКРЯ — базу синонимичных групп, построенную на основе корпусов русского языка.
Для запроса "машина" система расширяла поиск на "автомобиль", "тачка", добавляя их леммы в запрос с пониженной важностью (скажем, 0.8 от оригинала), чтобы не терять релевантность, но расширять охват.
Поисковые системы научили нас быстро находить информацию в безграничном интернете. Но внутри компаний существует та же проблема: нужные знания часто теряются в чатах, документах и архивах. И здесь уже нужен свой Google или Яндекс — только не по всему интернету, а по корпоративной базе знаний.
Чтобы правильные ответы всегда были под рукой, компании используют системы управления знаниями. Например, такие как Minerva Knowledge со встроенным ИИ-агентом Minerva Copilot, который полностью забирает на себя роль «поисковика».
Он понимает запросы сотрудников на естественном языке (даже с ошибками и опечатками), ищет информацию в базе знаний и выдаёт точный ответ за секунды. В отличие от обычного поиска, Copilot умеет не просто находить документы, но и подбирать конкретные инструкции, ссылки и статьи для принятия решений.
Так вместо хаоса файлов и заметок бизнес получает удобный инструмент для всей команды. А ещё — счастливых сотрудников, которые не тратят время на рутину и не отвлекают коллег в поисках нужной информации.
Узнать подробнее о продуктах Minervasoft
Google — PageRank и доминирование
Ларри Пейдж и Сергей Брин в 1998 году показали миру Google.
В основе поиска Гугла лежала крутая отличительная черта — не просто искать, а находить лучшее. Решал этот запрос алгоритм PageRank, который оценивал важность веб-страниц не по количеству ключевых слов, как делали AltaVista или Рамблер, а по их авторитетности, основанной на структуре ссылок в интернете.
PageRank, названный в честь Ларри Пейджа, моделировал интернет как ориентированный граф, где страницы — это вершины, а ссылки между ними — рёбра. Идея подпитывалась академическим цитированием: если на статью ссылаются сотни учёных, она, скорее всего, значима. Точно так же страница, на которую ссылаются другие сайты, особенно авторитетные, считалась более важной.
Как работает PageRank
Google придумал PageRank, чтобы определить, какие страницы в интернете важнее. Идея была такая: каждая страница отдаёт часть своей «важности» тем, на кого ссылается. Если на страницу ссылаются другие сайты — значит, она сама становится популярной.
Вначале все страницы считались равными. Потом алгоритм многократно пересчитывал важность страниц, перераспределяя его по ссылкам, пока значения не стабилизировались. В среднем нужно было несколько десятков пересчетов, и результат показывал, какие страницы действительно являются «центрами притяжения» в сети.
Идейно PageRank основан на вероятностной модели, которая имитирует поведение пользователя, гуляющего по интернету. Человек с вероятностью ( d ) (обычно 0.85) переходит по случайной ссылке на текущей странице, а с вероятностью ( 1-d ) "прыгает" на любую другую страницу в интернете.
PageRank присваивает каждой странице числовую важность, отражающий её значимость, где важность образуют распределение вероятностей, а их сумма по всем страницам равна 1.
При этом отдельные страницы могут иметь важность, превышающие 0.1 или даже больше, в зависимости от размера графа и структуры ссылок. Для удобства Google масштабировал эти значения (например, в публичной версии PageRank для тулбаров использовалась шкала 0–10).
Формула PageRank для страницы ( i ):
[PR(i) = \frac{1-d}{N} + d \sum_{j \in B_i} \frac{PR(j)}{L(j)}]
Где:
( PR(i) ) — PageRank страницы ( i ).
( N ) — общее число страниц в индексе.
( d ) — демпфирующий фактор (обычно 0.85), моделирующий вероятность перехода по ссылке.
( B_i ) — множество страниц, ссылающихся на страницу ( i ).
( PR(j) ) — PageRank страницы ( j ), которая ссылается на ( i ).
( L(j) ) — число исходящих ссылок со страницы ( j ).
Термин ( \frac{1-d}{N} ) учитывает случайные переходы, а вторая часть суммирует вклад от страниц, ссылающихся на ( i ), пропорционально их PageRank и количеству исходящих ссылок. Это подтверждает идею, что ссылка от популярной страницы ценнее, а страница с множеством исходящих ссылок передаёт меньше важности каждой.
Также в Google очень следили за "зависающими узлами" (dangling nodes) — страницам без исходящих ссылок, которые могли "захватывать" важности и нарушать устойчивость алгоритма. В этом случае компания перераспределяла важности таких страниц равномерно по всем остальным, добавляя их вклад в ( \frac{1-d}{N} ) на каждой итерации.
Для вычисления PageRank Google использовал итеративный метод. Изначально каждой странице присваивался равный важности (( 1/N )). Затем алгоритм пересчитывал важности, пока значения не сходились (обычно за 50–100 итераций, в зависимости от размера графа). Технически это сводилось к поиску стационарного распределения матрицы переходов ( M ), где ( M_{ij} = 1/L(j) ), если страница ( j ) ссылается на ( i ), и 0 в противном случае. Модифицированная матрица с учётом демпфирующего фактора: ( M' = d \cdot M + (1-d)/N \cdot E ), где ( E ) — матрица из единиц. Итоговый вектор PageRank решался через итерацию ( PR^{k+1} = M' \cdot PR^k ).
Вот вам практический пример на основе трёх сайтов:
сайт A ссылается на B и C,
сайт B — только на C,
сайт C ни на кого не ссылается.
Что происходит:
У A почти нет «ценности», ведь на него никто не ссылается.
B получает немного важности от A, но ничего больше.
C получает ссылки и от A, и от B, поэтому постепенно становится самым «важным» узлом. Алгоритм повторяет это распределение «голосов важности» снова и снова, пока баланс не устанавливается. В итоге видно, что именно на C приходится наибольшая часть важности — потому что на него чаще ведут ссылки.
То есть PageRank работает как система голосования, где ссылка — это голос доверия. Чем больше таких голосов (и чем важнее голосующие сайты), тем выше рейтинг страницы.
Или если раскрыть это подробнее:
На трёх страницах: A, B и C. A ссылается на B и C, B ссылается на C, а C — зависающий узел (без исходящих ссылок). Пусть ( d = 0.85 ), ( N = 3 ). На первой итерации:
( PR(A) = PR(B) = PR(C) = 1/3 \примерно 0.3333 ).
На следующей итерации, учитывая перераспределение важности C:
( PR(A) = (1-0.85)/3 + 0.85 \cdot 0 \примерно 0.05 ) (никто не ссылается на A).
( PR(B) = (1-0.85)/3 + 0.85 \cdot (1/3)/2 \примерно 0.05 + 0.1417 = 0.1917 ) (A передаёт половину своего PR).
( PR(C) = (1-0.85)/3 + 0.85 \cdot ((1/3)/2 + 1/3) \примерно 0.05 + 0.2833 = 0.3333 ) (A и B ссылаются на C).
Важность C затем перераспределяется равномерно: его ( PR(C) ) делится на ( N ), добавляя ( 0.3333/3 \примерно 0.1111 ) к каждой странице на следующей итерации. После нескольких итераций значения стабилизируются, показывая, что C получает наибольшую важность из-за большего числа входящих ссылок.
Интеграция с поиском
PageRank был не единственным компонентом поиска Google, скорее дополнением к текстовому анализу. Googlebot сканировал интернет, создавая инвертированный индекс, где слова связывались с документами через TF-IDF, о котором я сказал выше.
Для запроса "программирование" система находила документы с этим словом, вычисляла их текстовую релевантность (TF-IDF), а затем добавляла PageRank как отдельный ценностный (важность) коэффициент, чтобы приоритизировать авторитетные страницы. Например, страница MIT с высоким PageRank и умеренным TF-IDF могла обойти страницу с высоким TF-IDF, но низким PageRank. Так Google использовал линейную комбинацию факторов (TF-IDF, PageRank, анкорный текст), с важностью, настроенной эмпирически.
Анкорный текст ссылок играл ключевую роль: если на страницу вела ссылка с текстом "лучший курс программирования", это увеличивало её релевантность для запроса "программирование". Google анализировал HTML-теги <a> и их атрибуты, добавляя анкоры в индекс как дополнительный сигнал.
К июню 2000 года Google индексировал более миллиарда страниц (в 1999 году — около 50 миллионов), что помогло ему обойти AltaVista и стать лидером по объёму и качеству выдачи.
А ещё Google поменял подход к монетизации. Если Рамблер и Yahoo зарабатывали на баннерах, Google ввёл контекстную рекламу через AdWords — ненавязчивую и привязанную к запросам. Так он рос и не бесил пользователей, одновременно задавая тренды для рунета, где Яндекс позже запустил свой "Директ".
Скрытые возможности и операторы поиска
Но PageRank — только начало истории. Вообще у Гугла целый арсенал скрытых возможностей, о которых мало кто знает.
Рассказываю о поисковых операторах — командах, которые сделают ваш поиск мгновенным и точным.
Основные операторы Google 2025
Операторы для точного поиска
"точная фраза" — кавычки заставляют Google искать именно эту фразу. Например, "машинное обучение в медицине" найдёт только страницы с такой последовательностью слов, а не разрозненные упоминания машинного обучения и медицины.
слово -исключение — минус исключает ненужные результаты. Запрос ягуар -автомобиль покажет информацию о животном, исключив статьи про машины Jaguar.
слово1 OR слово2 — логическое ИЛИ расширяет поиск. "машинное обучение" OR "искусственный интеллект" найдёт материалы с любым из терминов.
слово* — звёздочка работает как джокер. "лучш* способ*" найдёт "лучший способ", "лучшие способы", "лучшая способность" и так далее.
Операторы для поиска на сайтах
site:domain.com — ищет только на конкретном сайте. site:habr.com нейронные сети покажет статьи о нейронных сетях только с Хабра.
related:domain.com — находит похожие сайты. related:stackoverflow.com выдаст сайты для программистов типа GitHub или Reddit.
inurl:слово — ищет слово в URL страницы. inurl:blog найдёт страницы с "blog" в адресе, что полезно для поиска блогов.
intitle:слово — ищет в заголовках страниц. intitle:"машинное обучение" найдёт страницы с этой фразой именно в заголовке.
Специализированные операторы
filetype:pdf — поиск конкретных типов файлов. "глубокое обучение" filetype:pdf найдёт только PDF-документы на эту тему.
AROUND(X) — слова должны находиться рядом. "Python AROUND(3) машинное обучение" найдёт страницы, где эти термины стоят в пределах 3 слов друг от друга.
define:слово — мгновенное определение. define:трансформер покажет определения этого термина из словарей.
weather:город — текущая погода. weather:Москва сразу покажет прогноз погоды.
Дополнительные команды
Поиск по датам и ценам
2020..2025 — поиск в диапазоне. "исследование ИИ" 2023..2025 найдёт только свежие исследования.
$100..$500 — поиск по ценам. iPhone $200..$400 покажет айфоны в этом ценовом диапазоне.
Анализ конкурентов и SEO
inanchor:текст — поиск по анкорным текстам ссылок. Полезно для анализа того, как конкуренты получают ссылки.
allintext:слова — все слова должны быть в тексте страницы. Помогает найти страницы с глубоким разбором темы.
cache:URL — показывает кэшированную версию страницы. Полезно, когда сайт недоступен или изменился.
Google Scholar: Академический поиск
Для научной работы у Google есть отдельная поисковая система — Google Scholar. Она использует специальные операторы:
author:"фамилия" — поиск по автору. author:"Hinton" найдёт работы Джеффри Хинтона.
allintitle:keywords — все слова в названии статьи. allintitle:transformer attention mechanism найдёт статьи с этими терминами в заголовке.
source:журнал — поиск в конкретном журнале. Например, source:"Nature Machine Intelligence".
Скрытые фишки Google
Помимо операторов, Google прячет множество пасхальных яиц и полезных функций
Калькулятор: просто введите математическое выражение
Конвертер: 10 долларов в рублях или 100 км в милях
Таймер: таймер на 5 минут
Случайное число: random number generator
Переводчик: translate hello to russian
Практические комбинации операторов
Реальная тема раскрывается при комбинировании операторов
text
site:github.com "machine learning" filetype:ipynb python -tensorflow
Эта команда найдёт Jupyter-ноутбуки по машинному обучению на GitHub, написанные на Python, но без использования TensorFlow.
text
"remote work" OR "удалённая работа" site:hh.ru OR site:superjob.ru
Поиск вакансий удалённой работы на российских job-сайтах.
text
intitle:weekly OR intitle:report "company performance" filetype:pdf 2024..2025
Поиск корпоративных отчётов в формате PDF за последние годы.
Ограничения и нюансы
Важно понимать, что не все операторы работают идеально
Данные по inanchor: и inurl: — только выборочные, не полные
Некоторые операторы не работают в мобильной версии
cache: показывает не самую свежую версию
Операторы чувствительны к пробелам и регистру
Эти операторы превращают Google из простого поисковика в швейцарский нож для работы с информацией. Освоив их, вы сможете находить нужную информацию в разы быстрее — будь то научные статьи, техническая документация или анализ статей других айтишников.
Yandex
Яндекс начинал как поисковая система, которая учитывает языковой контекст. Сейчас он — ну, вы и сами знаете.
У компании стояла амбициозная задача — сделать поиск, который понимает русский язык лучше всех. К 2025 году его доля в рунете составляет более 60%, и это не только за счёт поиска.
Залог успеха этой истории — локализация. Яндекс хорошо понимает российский контекст: от сложных запросов вроде "расписание электричек Тула–Москва" до культурных приколов, таких как подборка фильмов к 8 Марта. Его алгоритмы учитывают не только морфологию, но и разговорные формы: запрос "где поесть недорого" обрабатывается так же естественно, как если бы вы спросили об этом друга.
В 2024 году Яндекс обновил свой алгоритм, добавив нейросетевые модели, которые лучше понимают сложные и длинные запросы.
Его голосовой ассистент Алиса, запущенный ещё в 2017 году, сейчас — один из самых продвинутых в мире.
Нейросети также апгрейднули поиск до нового уровня. В 2023 году Yandex внедрил YATI (Yet Another Transformer Intelligence), который анализирует семантику запросов и выдаёт более точные результаты. Например, запрос "как починить кран" теперь выдаёт не только статьи, но и видеоинструкции или мастеров из Яндекс.Услуг, если вы добавили город. Это ответ на конкуренцию с ИИ-поиском, вроде Perplexity AI.
И Яндекс чуть меньше критикуют за вопросы приватности, чем Google, хотя и он собирает данные для персонализации.
И хоть Google доминирует в мобильном поиске (на андроиде), Яндекс любят юзать на десктопах и те, кому нравится формат экосистемы.
Практическая часть - как искать на Яндексе
Да, в Яндекс-поисковике тоже есть куча скрытых команд и операторов. Эти инструменты особенно нужны SEO-специалистам, маркетологам и аналитикам.
Морфологические операторы для русского языка
В отличие от Google, Яндекс глубоко понимает русскую морфологию, и это даёт уникальные возможности.
Операторы для работы с формами слов
!слово — поиск точной формы слова. Например, !книга найдёт именно "книга", исключив "книги", "книгами", "книжка". Это критично для русского языка с его падежами и склонениями.
"точная фраза" — поиск фразы с сохранением порядка слов. "купить дом в Москве" найдёт именно эту последовательность, но с учётом морфологии: "купила дом в Москве", "купить дома в Москве".
+"обязательное слово" — включение стоп-слов и предлогов. Запрос +в Москве заставит учитывать предлог "в", который Яндекс обычно игнорирует.
Продвинутые морфологические команды
— джокер звездочка * обозначит пропущенное слово. "лучший * в городе" найдёт "лучший ресторан в городе", "лучший * врач в городе" и так далее.
& — слова в пределах одного предложения. ремонт & квартира найдёт страницы, где эти слова встречаются рядом в одном предложении.
&& — слова в пределах одного документа. Более мягкое условие, чем простой пробел.
Региональный и временной поиск
Яндекс — король локального поиска в рунете. Его региональные операторы работают гораздо точнее Google.
Региональные операторы
region:213 — поиск по региону (Москва — 213). пицца region:213 покажет пиццерии именно в Москве.
lr=регион — параметр региональности через URL. Например, yandex.ru/search/?text=такси&lr=2 для поиска такси в Санкт-Петербурге.
Временные операторы
date:YYYYMMDD..YYYYMMDD — поиск по диапазону дат. коронавирус date:20200301..20200331 найдёт новости о COVID-19 за март 2020 года.
within:X — документы за последние X дней. iPhone within:7 покажет новости об iPhone за неделю.
Операторы для SEO-задач
Для SEO-специалистов Яндекс предлагает мощные инструменты анализа.
Анализ сайтов и конкурентов
site:domain.com — поиск по сайту. site:habr.com нейросети найдёт все статьи о нейросетях на Хабре.
host:domain.com — поиск на хосте. host:blog.company.com покажет страницы конкретно с блога.
rhost:com.domain — поиск по домену в обратном порядке. rhost:com.yandex найдёт документы на всех поддоменах Яндекса.
url:"путь" — поиск в URL. url:"/blog/*" site:company.com найдёт все страницы блога.
Специальные SEO-операторы
inurl:слово — слово в URL страницы. inurl:catalog найдёт страницы каталогов.
intitle:слово — слово в заголовке. intitle:"купить телефон" покажет страницы с этой фразой в title.
mime:тип — поиск файлов определённого типа. mime:pdf SEO найдёт PDF-файлы по SEO.
lang:ru — поиск на русском языке. Полезно для фильтрации многоязычных сайтов.
Практические комбинации для профессионалов
Анализ конкурентов
text
site:competitor.ru intitle:"ключевое слово" -inurl:blog
Найдёт оптимизированные под ключ страницы конкурента, исключив блог.
Поиск дублей контента
text
"уникальная фраза из вашего текста" -site:yoursite.com
Покажет, кто скопировал ваш контент.
Региональный анализ
text
"стоматология" region:213 intitle:цены
Найдёт конкурентов-стоматологов в Москве с ценами в заголовках.
Мониторинг упоминаний бренда
text
"название бренда" -site:yoursite.com within:30
Свежие упоминания бренда за месяц на чужих ресурсах.
Секретные фишки Яндекса
Операторы для работы с файлами
filetype:расширение — поиск файлов. filetype:xlsx "отчёт" найдёт Excel-файлы с отчётами.
attachment:тип — поиск вложений. Особенно полезно для поиска документов в почте через Яндекс.
Социальные операторы
social: — поиск в соцсетях (работает ограниченно). Яндекс индексирует некоторые публичные страницы ВК и других российских соцсетей.
Ограничения и нюансы Яндекса
Важно понимать особенности системы
Региональность влияет на все запросы — результаты в Москве и Екатеринбурге могут различаться
Морфология работает агрессивнее Google — иногда нужно использовать ! для точности
Некоторые операторы работают не во всех интерфейсах (мобильная версия, API)
Персонализация сильнее — результаты зависят от истории поиска
Яндекс.Вебмастер и региональность
Для SEO критически важно правильно настроить региональность сайта
В Яндекс.Вебмастере указать основной регион сайта в разделе "Региональность"
Добавить микроразметку с адресами и телефонами
Использовать геозависимые ключи в контенте
Настроить Яндекс.Справочник для локального бизнеса
Поиск с ИИ: Perplexity AI, Google Gemini и другие языковые модели
Говоря о поисковой системе в 2025 году, нельзя даже случайно не упомянуть ИИ. Тем более, когда он везде: Perplexity AI, Google Gemini, ChatGPT и т.д.
Perplexity AI
Perplexity AI, запущенный ещё 2022 году, представляет собой веб-сканирование в реальном времени с мощью языковых моделей — GPT-4 и Claude 3.
В отличие от Гугла, который просто выдаёт ссылки, или Яндекс, который интегрирует сервисы, Perplexity синтезирует информацию и даёт прямой, структурированный ответ с указанием источников.
Его любят студенты, аналитики и другие эксперты. В рунете его чаще используют, когда нужен доступ к англоязычным источникам или более глубокий анализ — например, "тенденции ИИ в 2025 году" выдаст обзор с Reddit, научных статей и новостей.
Google Gemini: Интеграция ИИ в поискового гиганта
Google в 2024 году показал всем свой Gemini 2.5, интегрировав его в Google Search для диалогового и мультимодального поиска. Он может искать информацию текстом, голосом и даже изображениями, а его функция "Deep Research" (запущена в декабре 2024) напрямую конкурирует с Perplexity, давая контекстные и полные ответы на вопросы.
Хотя в рунете Gemini всё равно уступает Яндексу по локализации, он силён в глобальном охвате и интеграции с экосистемой Google. При этом Gemini критикуют за излишнюю зависимость от рекламной модели Google: ответы могут включать спонсорский контент, а это снижает доверие по сравнению с тем же Perplexity.
Ну и для сложных запросов Gemini может быть менее точным, чем специализированные ИИ-поисковики, из-за широкого охвата.
ChatGPT и другие LLM: Поиск как побочный эффект
Да, ChatGPT не создавался как поисковик, но с выходом SearchGPT в 2024 году всё-таки начал конкурировать в этой области. SearchGPT, интегрированный в ChatGPT, использует данные из интернета для ответов в реальном времени, но его сила — в диалоговой природе.
Другие LLM, такие как Claude от Anthropic, тоже пробуют себя в поиске, но результаты пока слабые. Claude лучше справляется с творческими задачами, чем с фактическими запросами, и в рунете его почти не используют. В целом, ChatGPT и подобные модели подходят для генерации идей или объяснений сложностей, но уступают Perplexity и Gemini в реальном поиске из-за отсутствия веб-сканирования или слабой локализации.
Практическая помощь по эффективным промптам для Perplexity AI
Perplexity AI сочетает в себе веб-сканирование в реальном времени и мощь LLM. Ключ к максимальной пользе — правильно составленные промпты.
Контекст + инструкция
«Проанализируй последние тренды в автоматизации маркетинга за 2024–2025 годы и представь ключевые выводы по сегментам B2B и B2C.»Формат вывода
«Сформируй ответ в виде таблицы: столбцы — тренд, источник, влияние на ROI.»Ограничение источников
«Используй только публикации из научных журналов и аналитических отчётов, указав URL.»Уточняющие вопросы
«Какие три главных риска связаны с внедрением RAG-подходов в корпоративных KMS?»Сравнительный анализ
«Сравни архитектуры GPT-4 и Claude 3 по параметрам latency, cost и качество ответов.»
Сравнение ChatGPT vs Perplexity vs Google Gemini
Инструмент |
Источник данных |
Сильные стороны |
Ограничения |
ChatGPT (SearchGPT) |
Веб-сканирование (в момент интеграции) + исторические данные |
Диалоговое взаимодействие, генерация идей |
Зависимость от кеша, возможны устаревшие данные |
Perplexity AI |
Веб-сканирование в реальном времени |
Точные ссылки на источники, структурированные ответы |
Меньше креативности, фокус на фактологии |
Google Gemini |
Индекс Google + мультимодальные данные |
Мультимодальность, Deep Research, интеграция экосистемы |
Рекламные влияния, локализация слабее Яндекса |
Что в итоге? Мы прошли большой путь от каталогов Yahoo до ИИ-поиска Perplexity AI. Но как вы думаете, каким будет поиск ещё через пару лет? Или10-20?
Больше полезной информации про ИИ и спорные вопросы в найме, менеджменте и планировании читайте в блоге Minervasoft.