Возраст домена

Происхождение и история термина

История интереса к возрасту домена связана с попытками учитывать прошлое веб-документов при поиске. В опубликованной 31 марта 2005 года патентной заявке Information retrieval based on historical data дата регистрации домена рассматривалась как один из возможных признаков времени появления документа. Другими вариантами были первое обнаружение документа поисковой системой и первое обнаружение ссылки на него. Уже в этой модели регистрационная дата и дата знакомства поисковика со страницей были разными основаниями оценки. ^[6]

Это исторический пример подхода, а не доказательство работы современного алгоритма Google. Заявка описывает возможные реализации; из неё нельзя вывести правило «каждый дополнительный год улучшает позиции». Она также не устанавливает, кто первым употребил выражение «возраст домена».

Развивались и способы получения исходных данных. WHOIS — способ запроса регистрационных сведений — постепенно дополнялся RDAP, протоколом доступа к регистрационным данным (Registration Data Access Protocol). По сообщению ICANN, организации, координирующей систему интернет-идентификаторов, аккредитованные регистраторы и общие доменные зоны предоставляли RDAP с 2019 года. С 28 января 2025 года ICANN обозначил RDAP основным источником таких сведений для gTLD, то есть общих доменов верхнего уровня. Это изменение способа доступа к данным, а не новая дата рождения зарегистрированных имён. ^[3]

Суть и механизм

Доменное имя здесь — имя, по которому запрашивают регистрационные сведения; сайт — размещённые по адресу страницы и материалы. Чтобы узнать возраст имени, нужна запись о регистрации. Чтобы узнать возраст проекта, нужны сведения о его запуске и публикациях. Подмена одного другим даёт правдоподобное число, но отвечает не на тот вопрос.

В справке Рег.ру для международных доменов используются три разных поля. Creation Date относится к регистрации, Updated Date — к изменению сведений, Registry Expiry Date — к окончанию регистрационного срока. Последнее поле помогает понять, до какого момента действует регистрация; вычитание его из сегодняшней даты не даст возраста. ^[2]

В RDAP сведения представлены структурированно: у события есть поле eventAction, описывающее действие, и eventDate с датой и временем. В примере стандарта registration означает регистрацию, а last changed — последнее изменение. Считать следует от события регистрации именно доменного объекта, а не от любой встретившейся в ответе даты. ^[1]

Виды и классификации

Для работы удобно разделить три вопроса. Это рабочее разграничение редакции, а не нормативная классификация доменов.

Search Console — сервис Google для работы со сведениями о сайте в поиске. В инструменте проверки адреса Last crawl показывает последний обход страницы поисковым роботом, то есть программой, которая получает её содержимое. Время отображается в местном часовом поясе пользователя. Это не дата первого обнаружения сайта. ^[5]

Такое разделение полезно даже в коротком отчёте. Вместо неопределённого «проекту десять лет» можно указать, что десять лет прошло после регистрации имени, а публикации проекта подтверждены только за последний год. Разница не означает ошибку: измеряются разные события.

Как применяется на практике

Учебный пример: команда готовит городской справочник и сравнивает два имени. Первое зарегистрировано раньше, но команда не получила материалов, показывающих прежнюю работу сайта. Для второго доступны собственные выпуски проекта с датами. В сравнительной таблице следует отдельно записать регистрационный срок и доступную историю публикаций. Назвать первый проект более опытным только по возрасту имени было бы необоснованно.

При проверке российских зон особенно важно читать пояснения сервиса. В документации Рег.ру поле «Дата регистрации» для .ru, .su и .рф описано как дата регистрации в Рег.ру либо переноса от другого регистратора. Следовательно, именно эта подпись в данном интерфейсе не позволяет без уточнения объявить дату первым появлением имени. Это особенность описанного источника, а не правило для всех сервисов и зон. ^[2]

Практический результат проверки — короткая карточка: доменное имя, источник сведений, название события, исходная дата, дата расчёта и результат. Если смысл поля не установлен, лучше написать «исходная дата требует уточнения», чем выдавать точный календарный расчёт за достоверную историю.

Как измерить или проверить

Сначала найдите регистрационную запись через подходящий для зоны источник. Для общих доменов можно начать с сервиса ICANN Lookup, использующего RDAP; он прямо рекомендован в сообщении ICANN. ^[3] Сохраните адрес источника и исходную дату вместе с названием поля. Это позволит другому специалисту проверить, от какого события получено число.

Далее задайте дату, на которую нужен возраст. Для сравнения нескольких имён используйте одну дату. Воспроизводимый вариант расчёта по календарным датам можно записать так:

Здесь A — число прошедших календарных дней; обе D — календарные даты, приведённые к одному часовому поясу. Вычитание означает подсчёт дней между датами, а не вычитание чисел, которыми записаны год, месяц и день. Это арифметическая запись принятого в статье определения, а не формула оценки качества сайта. Если важен возраст с точностью до часов, сохраняйте полные временные отметки и считайте интервал между ними.

Учебный расчёт: регистрация датирована 1 октября 2025 года, проверка — 1 ноября 2026 года. До 1 октября 2026 года прошло 365 дней, затем ещё 31 день октября. Получается 396 дней, или один календарный год и один месяц. Все даты примера приведены к одному часовому поясу; реальный домен здесь не проверяется.

Делить число дней на 365 и называть результат точным количеством календарных лет не следует: длина года бывает разной. Для краткого представления можно указать полные календарные годы и остаток либо оставить дни. Правило округления должно быть одинаковым для всех сравниваемых имён.

Проверка завершена, когда понятны исходное событие, источник, две даты и единицы результата. Если регистрационная дата отсутствует, возраст неизвестен, а не равен нулю. Если она позже даты проверки, сначала проверьте выбранное поле и даты: отрицательный результат не нужно автоматически превращать в ноль.

Ошибки, ограничения и спорные вопросы

Главная ошибка — превращать календарный срок в гарантию поисковых позиций. Такой расчёт сообщает только длительность выбранного интервала. Он не измеряет полезность материалов, непрерывность работы команды или результаты продвижения.

Отдельный риск связан с использованием истекших доменов. В марте 2024 года Google объявил политику против их покупки и переиспользования преимущественно ради манипуляции поисковой выдачей с помощью малополезного содержания. В том же сообщении компания допустила использование старого имени для нового оригинального сайта, созданного для людей. ^[4] Действующая страница правил сохраняет определение такого злоупотребления; нарушение может привести к снижению позиций или отсутствию сайта в результатах. ^[7] Поэтому сама смена проекта не равнозначна нарушению: значение имеют цель и содержание.

Ещё одна ошибка — приравнивать доступную регистрационную запись к полной биографии имени. Если нужно выяснить, какие проекты существовали раньше и были ли перерывы, одной даты недостаточно. Эти вопросы следует проверять отдельно и не заполнять пробелы предположениями.

Частые вопросы

Связанные термины

• indeksatsiya
• ssylochnyy-profil
• ruchnye-sanktsii
• faktory-ranzhirovaniya
• poiskovyy-robot