Lazy Badger

Lazy Badger
Рейтинг
228
Регистрация
14.06.2017
alaev:
В действительности я тут показывал сайт, который висел полгода по ВК запросам по Москве в ТОП 10

Захлопнись, "искперд"! Здесь разговор не про позиции, а про деньги (но пронафталиненные "гуру" даже этого неспособны понять, да?), для которых нужны конверсии, а для конверсий (обычно) - переходы, характеристикой которых является CTR

Для "СЕО-экспертов" это все может и не важно (только не нойте потом, получив поджопник от бизнеса), но пример - фтопку, пока там нет данных по кэшу за тот же период. Сайт может быть сколько угодно в топе или жопе, вопрос - как изменился ROMI в отчетный период

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

Если есть доступ, то Фрог подключается, получает и показывает (много разного). Через API он может тянуть данные с Аналитики, Консоли, Majestic, Ahrefs, Moz

SmileP:
У Деваки был эксперимент.

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

1. Нет

2. Никак или "плохо", потому что снизится (возможно) такой параметр, как "широта товарного ассортимента"

Но решение (нормальное, прямыми руками если делать) очевидное - это а) "ничего не закрывать от индексации принудительно " б) использовать canonical на базовую карточку товара из всех мест, где он может в структуре показываться дополнительно.

Дополнительные пояснения нужны?

LiteCat:
может быть сезонное изменение CTR

А есть еще и изменения CTR страниц сайта, и не всегда - в лучшую сторону. Даже если "ничего не делали", то CTR все равно отслеживать надо и корректировать сниппет по показаниям

LadiesBoy:
А нагрузка будет на ДНС сервер домена прокладки?

Будет. Больше, чем сейчас - точно. А насколько - сильно зависит от многих причин, так что посчитать - затруднительно

LadiesBoy:
На случай, если доменов будет 1000+

Да хоть сотня тыщ. Зависимость там сильно нелинейная, данных для расчета нет, потому что важно и

- распределение посетителе по времени

- распределение по географии (точнее - првайдерам)

- политика кэширования на ресолверах провов

- TTL записи прокладки

Подробно все расписывать или хватит "на пальцах" простого примера? Предположим, что от моего оператора запросов к сайтам не было и я первый. Тогда, чтобы получить IP

1) ДНС оператора запрашивает у ДНС аплинка

2) если у того данных нет (а могут быть), он запрашивает у уже своего аплинка

3) см. п.2

4) в самом худшем случае (редком), если ни у кого из неавторитетных серверов ответа нет - запрос доходит до ДНС на клауде, он отвечает

5) После этого все задействованные по цепочке на все запросы всех клиентов (сколько бы их ни было) в течение TTL ответ знают и отвечают сами... а некоторые еще и кладут на TTL и кэш держат вечно

Понятно, почему увеличение просчитать нельзя?

LadiesBoy:
Мне нужно, чтобы можно было не менять А запись на 200 доменах

Да все (способные понять) уже поняли, о чем вопрос. Можно и даже нужно. Можно обойтись одном общим хостом, главное - не забыть "прямо щяз" поставить у него небольшой TTL (минуты-десяток) специально, чтобы изменения адреса быстрее разошлись при необходимости

Sitealert:
Мне кажется, ТС другим вопросом интересуется - как не заморачиваться с изменением IP для 1000 сайтов.

Не кажется, а так и есть. Только выражаться ТС внятно не может и приходится заниматься декриптовкой сообщения

---------- Добавлено 24.09.2019 в 23:45 ----------

smart2web:
Так то CNAME для 2го уровня доменов не доступен

Умняк продавил? Маладэц, возьми пирожок с полки. Только вот в вопросе не понял ты ни хрена, но вот мнение свое засветить - в обязы. Ох уж это поколение жоп, ни подумать, ни промолчать

Nadejda:
Смысл в том, что ни один из отписавшихся, не понимает смысла RSS

"Чрезмерная генерализация вредна". Я знаю, к примеру, как и то, что это - отмирающая технология для массмаркета

Всего: 3013