Не так давно Яндекс изменил RPS для XML-поиска

Некоторое время назад Яндекс изменил RPS для XML-поиска, об этом сообщалось каждому клиенту в электронном письме. Если вы письмо пропустили, то воспользуйтесь данной инструкцией.

 

Большинство владельцев сайтов — не важно, личных блогов ли, либо неких крупных проектов, используют Яндекс сервисы по отслеживаю оптимальной работы своих площадок. SEO-продвижение (или раскрутка) сайтов — необходимая составляющая компонента на пути к успеху. А посему все мы знаем, что SEO требует по возможности точный анализ данных скажем, о конкурентах, из различных источников.

 

Анализировать крупные объемы данных помогаю сервисы Яндекса. Один из них Яндекс XML:

 

 

Разделы статьи:

• Если Яндекс изменил RPS для XML — то как настроить по-новому
• XML-лимит – суточное ограничение количества запросов 1 пользователя
• XML-лимит включает:
• яндекс изменил RPS — ограничения на количество запросов в секунду (RPS)

 

 

Процесс продвижения требует изучения обстоятельств на web рынке: результаты выдачи ключевых запросов; отслеживать индивидуальные особенности поведения пользователей сайта и прочая и прочая…

 

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

 

 

Ключевая задача отработки данного сервиса сводится к тому, что «инструментарий сервиса» отправляет (в соответствии с настройками в аккаунте) запросы к поисковой системе Яндекса, ответы на которые получает в формате XML (все это легко копируется и читается).

 

 

Чтобы перенастроить опции XML сервиса, необходимо пройтись по ссылке — авторизоваться… либо, если вас еще нет в вебмастере Яндекса, пройти процедуру регистрации. Этот сервис важен!

 

 

Некоторое время назад Яндекс изменил RPS для XML-поиска

 

 

По кнопке «Тест» возможно пройти тестирование настоек…

 

 

к оглавлению

Если Яндекс изменил RPS для XML — то как настроить по-новому

 

 

Как сказано в документации: Яндекс ввел некоторые ограничения в работе сервиса — якобы для обеспечения бесперебойности (и безопасности) в работы с сервисом Яндекса.

 

к оглавлению

XML-лимит – суточное ограничение количества запросов 1 пользователя

 

 

XML-лимит включает:

 

 

• среднесуточное ограничение количества запросов ОДНОГО пользователя;
• лимит выделяется для каждого сайта автоматически — в зависимости от Индекса качества площадки;
• часовые ограничения — относится к дополнительным. Лимиты высчитываются в процентах допустимых от суточного количества запросов.

 

 

Если ограничение (суточное) на количество запросов, скажем, 1000. То в этом случае с 7:00 до 19:00 (на каждый час) разрешается задавать не более 5% запросов от установленного лимита (50 запросов см. на фото выше).

 

 

Например, так называемые нерабочие ночные часы: с 0:00 до 7:00 утра не было отправлено НИ одного запроса, то и в этом случае, с 7:00 до 19:00 превышение в 50 запросов недопустимо (т.е. экономия лимита невозможна — «простой» сгорает) — ограничение есть ограничение!

 

Таким образом в так называемые сутки получается что возможны отправления не более 600 запросов!

 

 

 

 

к оглавлению

яндекс изменил RPS — ограничения на количество запросов в секунду (RPS)

 

 

Обратите внимание на параметр (rps_restriction) — формирование определенного допустимого количества запросов в секунду в полной зависимости от часового ограничения (hourly_limit) — индивидуально для сайта!

 

 

Как и говорилось выше — до 20 февраля 2023 г. требуется внести коррекции в настройки XML сервиса.

 

 

Ранее почасовая квота (при расчете) зависела от разделения на 2000, теперь же при расчете RPS на 3420.

 

 

Для визуалов схема приблизительно выглядит так:

 

 

rps_restriction = hourly_limit / 3420

 

 

 

Важно: превышение порога hourly_limit — нарушения правил — как правило ведет к ошибкам!

 

 

 

 

Подключаем Турбо Страницы Яндекса (на ютюб-канале — есть видео о том, как удалить эти Турбо страницы из индекса Яндекса, если потребуется. Многие подключают, а потом решают избавиться от этих турбо… А задача не так уж и проста!..

 

 

 

 

 

Отключаем Турбо страницы Яндекса

 

 

 

 

. ..вопросы в комментариях — помогу, в чём дюжу…
mihalica.ru !

Михаил ATs — владелец блога запросто с Вордпресс — в сети нтернет давным-давно…

…веб разработчик студии ATs media: помогу в создании, раскрутке, развитии и целенаправленном сопровождении твоего ресурса в сети… — заказы, вопросы… разработка…

Прощай, XML, здравствуй, SQL! ClickHouse User Management Goes Pro

Контроль доступа — одна из важнейших функций управления базами данных. Начиная с конца 2019 года участник ClickHouse Виталий Баранов начал внедрять надежный полнофункциональный контроль доступа на основе ролей (RBAC). В результате этой работы, которая включала в себя огромное количество тестов, проведенных командой Altinity QA, ClickHouse теперь может по праву похвастаться контролем доступа на уровне предприятия. Лучше всего то, что все команды написаны на SQL.

Управление пользователями — это парадные ворота RBAC. Он сам контролирует доступ к ClickHouse. В этой статье рассматриваются новые команды, такие как CREATE USER, которые позволяют удобно создавать, изменять и удалять пользователей. Мы сосредоточимся на способах управления аутентификацией для отдельных серверов ClickHouse.

Попутно статья содержит советы, как получить максимальную отдачу от управления пользователями SQL, не открывая при этом новые дыры в безопасности. Пойдем!

Управление пользователями ClickHouse старой школы

Пользователи ClickHouse изначально определялись с помощью XML-файлов. Это все еще работает сегодня. Все, что вам нужно сделать, это поместить следующее определение в файл с именем root.xml и поместить этот файл в /etc/clickhouse-server/users.d.

 <яндекс>
<пользователи>
<корень>
2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b
<сети>
127.0.0.1

<профиль>по умолчанию
по умолчанию
1


 

ClickHouse автоматически распознает файл без перезапуска, и вы сможете войти в систему с помощью следующей команды:

 clickhouse-client --user=root --password=secret  

Созданное нами определение пользователя root имеет три интересных особенности.

1. Пароль хранится в виде хэша SHA256, поэтому фактическое секретное значение пароля не сразу видно. С другой стороны, он находится в файловой системе и подвергается атаке по словарю, если попадет в руки злоумышленника.
2. Используется маска сети для ограничения входа в систему на локальном хосте.
3. Включает управление доступом, помещая значение 1 в тег .

Последнее является наиболее важным для остальной части статьи. Это означает, что этот логин, root, может выполнять SQL-команды, связанные с управлением пользователями. Давайте войдем в систему, используя root, как показано выше, и начнем пробовать.

Управление пользователями SQL

В версиях ClickHouse после 20.5 есть команды SQL, которые управляют полным жизненным циклом операций над пользователями. Например, мы можем создать пользователя следующим образом.

 ch-1 :) СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ, ЕСЛИ НЕ СУЩЕСТВУЕТ пример ИДЕНТИФИКАЦИЯ SHA256_PASSWORD BY 'secret';
CREATE USER IF NOT EXISTS example IDENTIFIED WITH sha256_hash BY '2BB80D537B1DA3E38BD30361AA855686BDE0EACD7162FEF6A25FE97BF527A25B'
0 строк в наборе.  Прошедшее: 0,001 сек. 

ClickHouse автоматически генерирует хэш SHA-256, что удобно. Мы можем так же легко изменить пароль, используя команду ALTER USER. Это сгенерирует еще один хэш SHA-256 и сохранит его правильно.

 ALTER USER пример
ИДЕНТИФИКАЦИЯ С SHA256_PASSWORD BY 'topsecret'; 

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

  ПОКАЗАТЬ ПОЛЬЗОВАТЕЛЕЙ
┌─имя─────┐
│ по умолчанию  │
│ пример  │
│ корень     │
└──────────┘ 

Мы также можем посмотреть, как был создан конкретный пользователь.

 Пример ПОКАЗАТЬ СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ
┌─CREATE USER пример─────────────────────────────────┐
│ ПРИМЕР СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ, ИДЕНТИФИЦИРОВАННОГО С sha256_password │
└─────────────────────────────────────────── ─── ────┘ 

Наконец, мы можем отказаться от пользователя, когда он больше не нужен.

 DROP USER example 

Пользователи MySQL заметят, что команды управления пользователями звучат для них знакомо. Синтаксис MySQL сильно повлиял на ClickHouse. Синтаксис, на мой взгляд, вполне дружелюбен.

Более реалистичный пример

До сих пор мы показывали очень простые команды, но CREATE USER и связанные с ним команды достаточно эффективны и охватывают весь спектр управления учетными записями, включая профили пользователей, квоты и роли. Следующие команды создают профиль настроек пользователя, роль для запросов только для чтения, квоту для роли и пользователя, у которого есть все это.

 СОЗДАТЬ ПРОФИЛЬ НАСТРОЕК, ЕСЛИ НЕ СУЩЕСТВУЕТ ro_profile
НАСТРОЙКИ
max_threads = 2 МИН 1 МАКС 4,
max_memory_usage = 10000000 МИН 1000000 МАКС 20000000
ТОЛЬКО ДЛЯ ЧТЕНИЯ
СОЗДАТЬ РОЛЬ, ЕСЛИ НЕ СУЩЕСТВУЕТ ro_role
НАСТРОЙКИ ПРОФИЛЯ 'ro_profile'
СОЗДАТЬ КВОТУ, ЕСЛИ НЕ СУЩЕСТВУЕТ batch_quota
ЗА ИНТЕРВАЛ 3600 секунд
МАКС. запросов 60,
МАКС. результатов_рядов 1000000
ро_роль
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ ro_user
ИДЕНТИФИКАЦИЯ С SHA256_PASSWORD BY 'top_secret'
РОЛЬ ПО УМОЛЧАНИЮ ro_role 

Если непонятно, как связаны сущности, вот картинка:

Теперь вы можете использовать вход в систему для этого пользователя и проверять настройки и привилегии, назначенные пользователю через роль.

 clickhouse-client --user=ro_user --password=top_secret 

Мы можем выполнить быстрый запрос настроек, чтобы убедиться, что профиль установлен правильно.

 ВЫБЕРИТЕ имя, значение, мин., макс.
ИЗ системных.настроек
ГДЕ имя В ('max_threads', 'max_memory_usage')
┌─имя─────────────┬─значение────┬─мин─────┬─макс──────┐
│ max_threads      │ 2        │ 1       │ 4        │
│ max_memory_usage │ 10000000 │ 1000000 │ 20000000 │
— ─── ─┘ 

Мы также можем попытаться создать таблицу, чтобы доказать, что у учетной записи недостаточно прав для этого.

 CREATE TABLE foo (`id` UInt32) ENGINE = tinylog
Получено исключение от сервера (версия 21.1.2):
Код: 497. DB::Exception: получено с локального хоста:9000. DB::Exception: ro_user: Недостаточно привилегий. Для выполнения этого запроса необходимо иметь грант CREATE TABLE ON default.foo. 

Вот домашнее задание: выяснить, как подтвердить, что ro_user имеет квоту. Я сделал это, предоставив SHOW QUOTAS ON *.

* пользователю ro_user. Таким образом, ro_user может запустить SHOW QUOTA и увидеть ограничения. Вероятно, есть другой способ сделать это.

Введение авторизации RBAC открывает возможности для управления доступом к данным, которых раньше не было. Наиболее очевидным улучшением является то, что теперь вы можете управлять доступом и привилегиями пользователей по сети вообще без доступа к локальной файловой системе. Как видно из приведенного выше примера, это также открывает возможность работы с несколькими арендаторами в одном ClickHouse. Изучение этого придется ждать будущей статьи.

На веб-сайте clickhouse.tech есть отличная справочная документация по командам RBAC, так что не стесняйтесь исследовать. Тем временем мы вернемся к нашей теме управления доступом пользователей к ClickHouse.

Политики безопасности в отношении паролей пользователей

Любая система, использующая локальные пароли, создает проблемы, связанные с управлением безопасностью. XML-файлы определений пользователей старой школы хранят пароли на диске, что, как правило, приводит в действие корпоративные группы информационной безопасности, которые узнают об этом.

Помогает ли управление пользователями SQL? Давайте посмотрим!

Для начала повторно запустим команду для создания примера пользователя.

 СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ, ЕСЛИ НЕ СУЩЕСТВУЕТ пример
ИДЕНТИФИКАЦИЯ SHA256_PASSWORD BY 'secret'; 

ClickHouse сохраняет полученное определение пользователя в /var/lib/clickhouse/access. Например, после запуска предыдущей команды я запускаю следующую команду, чтобы посмотреть, что сделал ClickHouse.

 cat /var/lib/clickhouse/access/ce4a5f48-a826-646e-0492-b13002481282.sql 
 ПРИСОЕДИНИТЬ ПРИМЕР ПОЛЬЗОВАТЕЛЯ, ИДЕНТИФИЦИРОВАННЫЙ С помощью sha256_hash BY '2BB80D537B1DA3E38BD30361AA859A72BDE0FEEACD716BDE0FEEACD716 5Б'; 

Короче говоря, пароли все еще на диске, но в новом месте. ClickHouse гарантирует, что этот каталог имеет такие разрешения, что только root или пользователь clickhouse могут получить к нему доступ. Однако, если вы создаете резервную копию /var/lib/clickhouse с помощью снимка файловой системы (например), ваш снимок будет содержать пароли либо в виде простого текста, либо в хешированной форме.

Вы можете переместить файлы управления пользователями в другое место, обновив тег в файле /etc/clickhouse-server/config.xml. Обязательно проверьте права доступа к файлам в новом месте, чтобы избежать утечки паролей.

Говоря о паролях, существует ряд вариантов паролей, помимо хеширования SHA-256. Вот пара примеров, которые вы вряд ли будете использовать в большинстве случаев.

 -- Пароль хранится в открытом виде; НЕ ДЕЛАЙТЕ ЭТОГО!
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ, ЕСЛИ НЕ СУЩЕСТВУЕТ example_text
ИДЕНТИФИКАЦИЯ С PLAINTEXT_PASSWORD BY 'secret';
-- Двойной SHA-1 для совместимости с MySQL.
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ, ЕСЛИ НЕ СУЩЕСТВУЕТ example_mysql
ИДЕНТИФИКАЦИЯ С DOUBLE_SHA1_PASSWORD BY 'secret'; 

В первом примере пароли хранятся на диске в виде открытого текста, где их может увидеть любой, у кого есть права на чтение файлов. Нет причин делать это. В последнем примере показано, как создать учетную запись, которая будет работать с клиентами MySQL. Он предназначен для поддержки клиентов MySQL, использующих протокол mysql_native_password.

И последний пример: никакого пароля!

 -- Для входа пароль не требуется.
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ, ЕСЛИ НЕ СУЩЕСТВУЕТ example_no_pw
ИДЕНТИФИКАЦИЯ С NO_PASSWORD; 

Если вы используете этот подход, вы должны ограничить доступ другим способом, иначе данные будут иметь очень низкое значение. В следующем разделе мы покажем, как ограничить доступ с помощью сетевых фильтров.

В целом пароли SHA-256 являются наиболее безопасным вариантом для локальных учетных записей. Если вас все еще не устраивает локальное хранение паролей на диске, вам повезло. ClickHouse теперь предлагает другой выбор. Вы можете хранить пароли и даже целые определения пользователей на центральном сервере LDAP. Мы обсудим это в следующей статье блога.

Защита учетных записей с помощью сетевых масок

В нашем последнем примере с паролем мы показали учетную запись без пароля. Это может показаться бесполезным с точки зрения безопасности, но на самом деле во многих случаях это весьма практично. ClickHouse позволяет ограничить доступ с помощью сетевых масок.

Вот простой пример: пользователь, который может войти только с локального хоста.

 СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ example_hostlocal
ИДЕНТИФИКАЦИЯ С NO_PASSWORD
HOST LOCAL 

Вход с других хостов завершится ошибкой с соответствующим двусмысленным сообщением об ошибке:

 clickhouse-client --user=example_hostlocal --host=ch-1
Версия клиента ClickHouse 21.1.2.15 (официальная сборка).
Подключение к ch-1:9000 как пользователь example_hostlocal.
Код: 516. DB::Exception: Получено от ch-1:9000. DB::Exception: example_hostlocal: Аутентификация не удалась: неверный пароль или нет пользователя с таким именем. 

Сетевые фильтры ClickHouse имеют ряд полезных вариаций. Вот пользователь, который ограничен входом в систему из определенной подсети.

 СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ example_subnet
ИДЕНТИФИКАЦИЯ С NO_PASSWORD
IP-адрес хоста «10.2.0.0/24» 

Далее пользователь, который может входить в систему с IP-адресов, соответствующих определенным хостам. Сетевые маски можно комбинировать, разделяя разные фильтры запятыми. Вы можете добавить столько фильтров, сколько хотите.

 СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ example_host
ИДЕНТИФИКАЦИЯ С NO_PASSWORD
ИМЯ ХОСТА 'ch-1', ИМЯ 'ch-2', ИМЯ 'ch-3' 

В последнем примере используется регулярное выражение для сопоставления логинов с хостов ch-1, ch-2 и ch-3. Он также имеет дополнительную маску HOST LOCAL, чтобы разрешить вход с локального хоста. Это определяет пользователя, который может войти в систему с трех именованных хостов, а также локально с хоста, на котором работает сам сервер. 9ch-[123]$’

Последнее замечание: остерегайтесь прокси! Если вы поставите обратный прокси NGINX перед сервером ClickHouse и подключитесь через него к HTTP-порту 8123 или 8443, ClickHouse увидит сетевой адрес прокси-хоста, а не исходного клиента. То же самое применимо, если вы завершаете TLS до того, как соединение достигнет ClickHouse. Вы увидите хост завершения, а не хост клиентской программы.

Таким образом, сетевые фильтры полезны, но не обеспечивают полной защиты доступа. Лучше дополнить их паролями, если у вас нет полного контроля над сетевым путем.

Заключение

Управление пользователями на основе SQL и контроль доступа на основе ролей представляют собой огромный шаг вперед для безопасности ClickHouse. В этой статье основное внимание уделялось управлению доступом к отдельным серверам ClickHouse. В следующей статье блога мы обсудим управление пользователями в кластерах ClickHouse.

Мы едва коснулись многих механизмов, которые теперь предлагает ClickHouse для защиты данных. Есть намного больше. Мой коллега Василий Немков только что опубликовал статью о функциях шифрования AES. Мы будем публиковать дальнейшие статьи о LDAP, RBAC, поддержке Kerberos (это уже происходит!) и многих других темах. Для получения полного обзора, который также включает вопросы конфиденциальности, ознакомьтесь с нашим недавним вебинаром ClickHouse Defense from the Dark Arts — Intro to Security and Privacy.

2021 год кажется отличным годом для безопасности ClickHouse. Свяжитесь с нами по адресу [email protected], если у вас есть вопросы о том, как решить проблемы, связанные с вашими вариантами использования. У нас также есть квалифицированная команда инженеров, готовая внедрить новые функции, если что-то упущено. В любом случае будем рады общению!

Чему 5 лет в России научили TripAdvisor Об оптимизации для России и поисковой оптимизации Яндекса

TripAdvisor впервые запустил оптимизированный для России сайт почти пять лет назад, в октябре 2010 года. потенциал роста в 2015 году и далее, Россия остается приоритетом для крупнейшего в мире туристического сайта.

С одной стороны, в России самое большое в Европе интернет-население с 83 миллионами пользователей и людей, которые любят путешествовать. С другой стороны, Россия и Рунет (российский Интернет) также имеют важные различия и уникальный набор проблем как для местного, так и для международного бизнеса.

Совершенно очевидно, что на большинстве зарубежных рынков предприятиям потребуется оптимизировать свои веб-сайты для местного языка и аудитории. Сложный русский язык требует еще большего внимания к аспекту локализации бизнеса. В отличие от большинства мест в мире, Google не является доминирующей поисковой системой. Россияне в значительной степени полагаются на свою местную поисковую систему Яндекс, которая поддерживает примерно 60% доли поискового рынка. Маркетологам поисковых систем и SEO-специалистам необходимо ознакомиться с Яндекс.Директ, рекламной платформой Яндекса на основе аукциона и Яндекс SEO.

Как вы все хорошо знаете, подготовка и приспособление к таким испытаниям требует тщательного планирования и практики. Чтобы лучше понять, как компании решают такие задачи, я взял интервью у вице-президента TripAdvisor по поисковой оптимизации Люка Левеска, который поделился своими знаниями и советами по оптимизации для российского рынка.

Почему TripAdvisor отдает предпочтение России по сравнению с другими регионами?

Это было сочетание языка и растущего российского туристического рынка. В 2010 году русский был 9-м по величине языком в Интернете, и наше исследование показало, что в то время было 60 миллионов пользователей Интернета. У TripAdvisor уже были сайты, охватывающие другие 10 самых популярных интернет-языков, за исключением арабского, который был запланирован на 2011 год, поэтому Россия была очевидным следующим выбором.

Если бы вам пришлось делать это снова, вы бы сделали что-то по-другому при запуске русского веб-сайта? Объяснять.

На русском веб-сайте было 3 большие проблемы: отображение/отступы, русская грамматика и местные списки. Мы были очень довольны сайтом, когда он был запущен, но мы могли бы запустить сайт лучше, если бы оценили уровень этих проблем раньше и выделили дополнительное время в нашем графике, чтобы более полно решить их перед запуском, вместо того, чтобы продолжать решать их. после запуска.

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

Грамматика русского языка: Русский был первым сайтом, где нам действительно пришлось решать проблемы со склонением. Мы особенно стремились к этому, потому что Яндекс вознаграждает сайты с хорошей грамматикой. На TripAdvisor много заголовков, например «1 из 50 отелей Москвы» или «Посмотреть все отели Москвы». В русском языке существительные меняют свои последние буквы в зависимости от их использования в предложении (функции падежа и падежа), и нам пришлось адаптировать переводы, базы данных и переменные строки, чтобы они соответствовали правилам русской грамматики.

Местные списки:  Большая часть контента, который у нас уже был для России, была получена от иностранных туристов, посетивших Россию. В результате рестораны и достопримечательности с отзывами, как правило, посещают иностранные туристы. Это означало, что нам не хватало многих отелей, ресторанов и достопримечательностей, особенно тех, которые посещали местные жители. Мы бы хотели запустить больше местных списков, но многие из них были добавлены только после запуска.

Каковы три самых больших отличия оптимизации для Яндекса от Google? Как это влияет на ваши SEO-приоритеты в России?

Яндекс значительно медленнее сканирует новые страницы и имеет гораздо меньший индекс по сравнению с Google. Таким образом, не надо тратить время Яндекс-бота на сканирование ненужных страниц. Этого можно добиться, добавив менее важные страницы в файл robots.txt, что сфокусирует внимание на более важных страницах, что позволит им быстрее индексироваться и ранжироваться.

В связи с тем, что на Яндексе мало написано по-английски, с какими самыми большими сюрпризами вы столкнулись?

Помимо уже упомянутого, было несколько технических сюрпризов:

Яндекс ограничивает размер файла robots.txt до 32 КБ, что меньше, чем поддерживает Google. Превышение этого лимита приведет к тому, что Яндекс полностью его проигнорирует, так что будьте осторожны.

В отличие от Google, Яндекс не будет следовать перенаправлениям на XML-карты сайта и требует, чтобы они размещались на том же поддомене, что и сайт.

Какие три самых важных первых шага нужно сделать новичкам, оптимизирующим на Яндексе?

Работайте в тесном контакте с носителями языка, чтобы получить правильный язык, так как высокий рейтинг в Яндексе с плохой грамматикой или машинным переводом будет очень сложным.

Зарегистрируйтесь в Яндекс.Вебмастере, который доступен на английском языке. Подобно инструментам Google для веб-мастеров, он предоставляет ценную информацию о многих аспектах сайта, таких как поисковые запросы и индексация.

Прочтите «Советы для веб-мастеров» Яндекса, в которых изложены их рекомендации относительно того, что они считают качественным сайтом, а также советы о тактике, которых следует избегать.

Какие три вещи вы делаете в первую очередь, чтобы углубить свои знания SEO в Яндексе?

1.