Опять с начала сентября стали проседать продажи. Поначалу списывал на начало учебного года, конец отпускного сезона и т.п., вчера полез посмотреть статистику. PayPro говорит, что страницу заказа открывают почти так же часто, как и в августе, но из десятка событий "Order Submit" успешно завершается лишь два-три. Что происходит с остальными — хз. Статистика посещений сайта говорит, что в сентябре оно увеличилось почти наполовину. В общем, как всегда, мутно.
Но насторожило совершенно непонятное явление: если в гуглопоиске набрать "virtual audio cable", то в позиции vac.muzychenko.net (она обычно идет второй-четвертой) почему-то вижу имя по-русски (не транслитерация с латиницы, а правильное русскоязычное написание), хотя ни на этом поддомене, ни на корневом домене нет ни одной страницы с русскоязычным написанием (они есть только на других поддоменах).
Сперва подумал, что как-то влияет русская локаль, попробовал из виртуалки со штатовской локалью — такая же фигня. Еще месяц назад такого не было — всегда было Eugene Muzychenko.
Попробовал через Bing и DuckDuckGo — там такого нет.
Это опять новые фичи гуглоинтеллекта? Если да, то что с этим делать?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но насторожило совершенно непонятное явление: если в гуглопоиске набрать "virtual audio cable", то в позиции vac.muzychenko.net (она обычно идет второй-четвертой) почему-то вижу имя по-русски (не транслитерация с латиницы, а правильное русскоязычное написание), хотя ни на этом поддомене, ни на корневом домене нет ни одной страницы с русскоязычным написанием (они есть только на других поддоменах).
Я искал яндексом и гуглом по запросу virtual audio cable
и мне везде выдавало вот это первой ссылкой. https://vac.muzychenko.net/en/
А так поисковики могут запоминать предпочтения пользователей, обычно учётку, но может и по ip что-то определяют.
ЕМ>Опять с начала сентября стали проседать продажи. Поначалу списывал на начало учебного года, конец отпускного сезона и т.п., вчера полез посмотреть статистику. PayPro говорит, что страницу заказа открывают почти так же часто, как и в августе, но из десятка событий "Order Submit" успешно завершается лишь два-три. Что происходит с остальными — хз.
А может это PayPro. Вообще некоторые обрадовались, что Россию загнобили, отключили кучу банков от Swift, ушла Visa и Mastercard. А что остаётся у людей, только все эти полулегальные платёжные говносистемы, да и то в мире, а не здесь.
И что? А я не знаю что. Где гарантия, что люди нажимают купить, а потом их не посылает погулять платёжная говносистема, через которую ты пытаешься продавать.
Не зря же во всём мире торговцы преимущественно отделены от производителей. Торговля это же целая отрасль, которая следит за тем, чтобы ничто не мешало покупки товара.
Сбои могут происходить во всём мире. В каждой стране свой способ оплаты. А платёжные говносистемы они сейчас есть и работают, а завтра они есть и не работают, или их уже нет.
Вот почему некоторые фритуплейные игры много зарабатывают. Да потому что там удобно тратить деньги в их внутренних магазинах.
Больше всего внутриигровых покупок в Genshin Impact оформили в Китае — на сумму 1,2 миллиарда долларов или на 33% от общего количества. На втором месте находится Япония — 24%, а замыкают тройку США — 17%.
То есть игра на движке Unity заработала больше всех на родине в Китае. А в США она столько заработала потому, что у них развиты платёжные системы.
Если же нет платёжных систем и сами компании не заморачиваются, то это не значит, что не было бы спроса. Я раньше платил за игры в Steam, Battle.net, немного даже купил в Origin. Сейчас нет возможности оплаты и я естественно ничего не плачу.
Ладно, я конечно теоретик в этом деле, но мне думается, что мелкие производители софта мало уделяют торговле. Нет яркой красивой обёртки вроде сайта продукта говорящей "КУПИ МЕНЯ". Нет нормальной системы оплаты для конкретной страны.
Я просто к чему говорю, что Genshin Impact имея финансовые возможности не спешит покорять мир. Ну вот какие усилия на продажи, такие и продажи. Альтернативная стратегия сделать какую-нибудь редкую штуку, чтобы все приходили только к тебе, но это такое себе.
Здравствуйте, velkin, Вы писали:
V>и мне везде выдавало вот это первой ссылкой.
Яндекс всегда выдает первой, поскольку мой неадекватный французский конкурент (VB-Audio) загадил ссылками на себя в основном англо- и франкоязычные сегменты. До этого гугл тоже выдавал в первой.
V>А так поисковики могут запоминать предпочтения пользователей, обычно учётку, но может и по ip что-то определяют.
Не понял. Какую "учетку" мог бы запомнить гугл, и где он там мог взять русскоязычное написание имени, которого в гугловских учетках никогда не было?
V>Где гарантия, что люди нажимают купить, а потом их не посылает погулять платёжная говносистема
Это здесь уже несколько раз обсуждали, и каждый раз приходили к выводу, что там не все в порядке, хотя PP клянется, что с их стороны все нормально.
Но тут многие продают через PP, и в последнее время никто не жаловался.
V>через которую ты пытаешься продавать.
Почему "пытаешься"?
V>Торговля это же целая отрасль, которая следит за тем, чтобы ничто не мешало покупки товара.
V>А платёжные говносистемы они сейчас есть и работают, а завтра они есть и не работают, или их уже нет.
Вас не смущает явное противоречие между этими утверждениями? "Говносистема" зарабатывает на продажах, и неслабо — 4-6-8%. Выходит, она "должна следить".
V>думается, что мелкие производители софта мало уделяют торговле. Нет яркой красивой обёртки вроде сайта продукта говорящей "КУПИ МЕНЯ".
Я уже несколько раз говорил, что умышленно не хочу зазывать тех, кто покупает красивую обертку, не глядя на то, что внутри. Такие потом выедают мозг жалобами "я думал ..., а оно ...".
V>Нет нормальной системы оплаты для конкретной страны.
PayPro и Verifone/Avangate — вполне себе нормальные системы оплаты для тех стран, которые лидируют по покупкам. Прикручивать отдельную систему для продажи в России имеет смысл не раньше, чем продукт будет локализован (пока руки не доходят).
At the top of the “About the source” section, you might find a description of the source from a reference site. These descriptions come from Google’s Knowledge Graph.
Google’s search results sometimes show information that comes from our Knowledge Graph, our database of billions of facts about people, places, and things.
Where do Knowledge Graph facts come from?
Facts in the Knowledge Graph come from a variety of sources that compile factual information. In addition to public sources, we license data to provide information such as sports scores, stock prices, and weather forecasts. We also receive factual information directly from content owners in various ways, including from those who suggest changes to knowledge panels they’ve claimed.
Далее секция "How to request a knowledge panel change or report a Knowledge Graph issue".
Здравствуйте, opfor, Вы писали:
O>Фамилия-то украинская, продажи наоборот должны расти
Фишка в том, что подавляющее большинство покупателей — из США, Германии, Австралии и т.п., для которых что кириллица, что иероглифы, что арабская вязь — сплошная абракадабра.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Фишка в том, что подавляющее большинство покупателей — из США, Германии, Австралии и т.п., для которых что кириллица, что иероглифы, что арабская вязь — сплошная абракадабра.
Я бы особо не переживал. С точки зрения обывателей, если Гугл на первом-втором месте показывает сайт какого-то чувака, причем на .net домене и крокозябрами в названии, то это только придает больше веса этому результату, потому как у Гугла, очевидно, есть какие-то весомые reasons показывать такую экзотику. Гугл knows better типа.
Здравствуйте, m2user, Вы писали:
M>Facts in the Knowledge Graph come from a variety of sources
Спасибо! Так и думал, что это очередные потуги псевдоинтеллекта.
M>Далее секция "How to request a knowledge panel change or report a Knowledge Graph issue".
А тут снова непонятки. Здесь сказано: "Search for yourself or the entity you represent and find its knowledge panel". А где эту knowledge panel можно find? Даже после авторизации в Google Account, "трехточечное" меню в выдаче открывает все тот же диалог "More Options", и ни в нем самом, ни в "More about this page" нет слова "knowledge".
Здравствуйте, wantus, Вы писали:
W>Я бы особо не переживал. С точки зрения обывателей, если Гугл на первом-втором месте показывает сайт какого-то чувака, причем на .net домене и крокозябрами в названии, то это только придает больше веса этому результату
Да ни хрена подобного. Подавляющее большинство тупо кликает по первому результату, а на второй даже не смотрит (не раз убеждался в этом, разъясняя людям, что они перепутали продукты/сайты). А те, кто смотрит на результаты ниже, теперь будут недоумевать, что там за кракозябры, и что они означают. Тут уже вполне может сработать недоверие ко всему непонятному — я б и сам на такое не пошел, если б не было сильно нужно.
W>Гугл knows better типа
Вот это уже начинает неслабо напрягать, ибо возможностей для ведения честного и прозрачного бизнеса становится все меньше, все чаще приходится жульничать поневоле.
Используя эти данные, поисковые машины имеют возможность именовать, группировать и категоризовать содаржимое домена. Это особенно полезно когда на одном домене есть несколько логических подсайтов. Но стоит помнить, что в поисковой выдаче будет фигурировать только самое главное (корневное) имя сайта, даже если есть несколько логических подсайтов.
Здравствуйте, Aquilaware, Вы писали:
A>Это известная проблема, и не только Гугла. Определение имени сайта происходит эвристически, если не указано явно.
Вот если б эти криворукие уроды хоть как-то намекали на эту "известную проблему" в своей Search Console, было б не так досадно.
A>нужно на главную страницу домена сайта добавить специальные метаданные:
Пакет JSON-LD там есть, а вот alternateName на тот момент, когда я его добавлял, там иметь не предлагалось. Добавил.
Еще у меня там было operatingSystem:Windows, но сейчас вдруг подумалось, что это может помешать показу результатов поиска на телефоне с Android/iOS, с которого пользователь ищет себе софт под винду на ноутбуке/десктопе. Или не помешает?
A>Имя сайта может быть только одно на домен.
Имеется в виду домен любого уровня — x.y.z.com и т.п., от которого растет дерево каталогов?
A>Также хорошим тоном считается задание свойства og:site_name (для каждой страницы сайта):
Спасибо, тоже не знал. Добавил.
A>
A> <meta property="og:site_name" content="Virtual Audio Cable" />
A>
Кстати, почему-то в примерах тэгов meta name закрывающего слэша нет, а в meta property — есть. Это просто традиция, или есть какие-то фактические различия?
A>в поисковой выдаче будет фигурировать только самое главное (корневное) имя сайта, даже если есть несколько логических подсайтов.
Если "корневое имя" — это то, что отдается при заходе в корень домена, независимо от его уровня, то это вполне логично.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Еще у меня там было operatingSystem:Windows, но сейчас вдруг подумалось, что это может помешать показу результатов поиска на телефоне с Android/iOS, с которого пользователь ищет себе софт под винду на ноутбуке/десктопе. Или не помешает?
Есть разные типы схем. Для https://schema.org/WebSite никаких ограничений по ОС не подразумевается, более того, их нет в схеме. А вот для https://schema.org/SoftwareApplication имеет смысл указывать поддерживаемые ОС. Схемы WebSite и SoftwareApplication — это две разные схемы со своими наборами атрибутов, но они обе могут сосуществовать на одной странице, если есть такая необходимость. Для этого используются отдельные теги script, в каждом из которых распологается своя схема.
Можно задавать несколько схем и в одном теге script, но для этого нужно использовать определение массива: https://stackoverflow.com/a/32954313, а не просто конкатенацию (это частая ошибка). Другими словами, то, что находится в теге script это не только текст, а еще и код, который должен быть валидным с точки зрения машины. В противном случае, поисковик не сможет распарсить схемы.
Для определения имени сайта поисковые машины используют схему WebSite. Если у вас на странице есть схема SoftwareApplication, но нет WebSite, то поисковая машина не будет использовать SoftwareApplication для определения имени сайта, так как эта схема задает только имя приложения, которое описывает страница, но не задает имени сайта.
A>>Имя сайта может быть только одно на домен. ЕМ>Имеется в виду домен любого уровня — x.y.z.com и т.п., от которого растет дерево каталогов?
Да. Имеется в виду домен с точки зрения DNS.
ЕМ>Кстати, почему-то в примерах тэгов meta name закрывающего слэша нет, а в meta property — есть. Это просто традиция, или есть какие-то фактические различия?
Это обусловлено разницей между HTML и XML. XML всегда требует закрывающих тегов, в то время как HTML их не требует в обязательном порядке. Но для порядка и для избежания неоднозначных ситуаций интерпретации разметки рекомендуется всегда использовать закрывающие теги. То есть писать на HTML так, как будто это формальный XML. Но это дело вкуса, есть разные мнения на этот счет.
С компа с Хрома из РФ по запросу "виртуальный аудио кабель" вы на третьем месте с заголовком "Евгений Музыченко". Потом на английском Virtual Audio Cable (VAC) — connect audio applications, route ...
С планшета под андроидом с Хрома из РФ вы на 6-ом месте без русского заголовка (вообще без заголовка). Потом на английском Virtual Audio Cable (VAC) — connect audio applications, route ...
Где-то описано, на что конкретно это влияет? Я опасаюсь, что указание Windows помешает людям с телефонов попадать на сайт, а ведь это вполне себе типовой случай — с телефона, пока где-то сидишь/едешь, поискать софт для "большого" компьютера.
A>Схемы WebSite и SoftwareApplication — это две разные схемы со своими наборами атрибутов, но они обе могут сосуществовать на одной странице, если есть такая необходимость.
Опять же, дает это предсказуемый эффект, или "как поисковик решит"? Лишняя информация может дать тот же негативный эффект, что и ее нехватка.
A>Для определения имени сайта поисковые машины используют схему WebSite.
По общей схеме — не будет?
A>XML всегда требует закрывающих тегов, в то время как HTML их не требует в обязательном порядке.
Вопрос в том, всегда ли парсеры HTML будут правильно понимать тэг meta name, в который добавлен закрывающий слэш, когда уже очень много лет их традиционно не закрывают.
Ещё у вас какое-то неправильное меню выбора языков
Там все языки перечислены на русском
Обычно каждый язык указывается на своём языке
И самые популярные — английский, французский в начале
Может кстати из-за этого он ваше имя переводит на русский?
Я бы эту штуку убрал. Всё равно Хром переводит автоматом сайты, если надо
Здравствуйте, TailWind, Вы писали:
TW>у вас какое-то неправильное меню выбора языков
У меня вообще нет никакого меню. Это гугловский апплет-переводчик, он это меню и рисует.
TW>Там все языки перечислены на русском
Я их вижу на английском. Скорее всего, зависит от локали, которую передает браузер.
TW>Может кстати из-за этого он ваше имя переводит на русский?
В выдаче — не перевод имени, а именно замена на его кириллическое написание. И тогда почему именно на русский, а не на суахили, к примеру?
TW>Я бы эту штуку убрал. Всё равно Хром переводит автоматом сайты, если надо
Так не все ж ходят через Хром. Но вскорости, наверное, уберу — аналитика показывает, что ее почти не используют.
ЕМ>У меня вообще нет никакого меню. Это гугловский апплет-переводчик, он это меню и рисует.
У меня интуитивное предчувствие что это всё из-за этого переводчика
Смотрите у вас title на основном сайте стоит ваше ФИО
И Гугл его выдаёт как название сайта (заголовок). И это правильно
У меня тоже в поиске выдаёт заголовок title основной страницы
А вот почему он его на русский перевёл. Мне кажется это из-за гугл переводчика
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Опять же, дает это предсказуемый эффект, или "как поисковик решит"? Лишняя информация может дать тот же негативный эффект, что и ее нехватка.
Как поисковик решит. Захочет в шапке написать что автор сайта маньяк — напишет.
ЕМ>По общей схеме — не будет?
Такого понятия как общая схема не существует.
ЕМ>Вопрос в том, всегда ли парсеры HTML будут правильно понимать тэг meta name, в который добавлен закрывающий слэш, когда уже очень много лет их традиционно не закрывают.
Посмотрите микроразметку
<script type="application/ld+json">
и
<meta name="author" content="Eugene (Evgenii) Muzychenko">
Может они подтынулись?
Потом еще микроразметки Site глянул и Organizatio или как их там и корректно заполнил. В общем работать в сторону Knowledge Graph, позоже это он)
Ладно напишу, хотя это и капитан очевидность
И уже ничего не исправить
Здесь изначально ошибка проектирования сайта
На этом форуме часто всплывают темы:
— делать отдельный сайт под программу или сайт компании с программами
— делать отдельный сайт под каждый язык или все языки на одном
Вот вам и ответ
И я понимаю если бы вы основной домен сделали = название компании
И название компании было бы запоминающимся и раскрученным
Тогда бы ваш VAC отличали от VAC конкурента в поиске по названию компании, которое всегда было бы латиницей
Но различать продукты по имени владельца, да которое ещё фиг запомнишь
Теперь либо всё переделывать
Либо личный бренд раскручивать. Мол VAC от Евгения Музыченко (как полное имя программы). И только этот правильный
А пока вы слились с конкурентом. Да вы это и сами пишите
Я понимаю ваше возмущение, но VAC это уже не ваш бренд. А название класса программ
Надо добавлять что-то к нему чтобы искалось в первых строчках
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А это тогда что?
Это схема для продукта. А вот это — это уже схема для вебсайта. А это — схема для программного приложения. Вы разницу улавливаете? Это разные типы схем, где каждая схема идет со своим набором атрибутов и используется для своих целей. Обращайте внимание на значение свойства @type.
Вы не можете брать атрибуты разных схем и просто так запихивать их в одну "общую" схему без указания конкретных типов. Идея такая же, как и в типизированном языке программирования: например, const char* и float это разные типы, работающие с разными данными.
Что и как именно "посмотреть"?
E>Может они подтынулись?
В каком смысле "подтянулись"?
E>Потом еще микроразметки Site глянул и Organizatio или как их там
Название организации применимо только к шаблону "организация", которое предусматривает адреса, телефоны, регистрационные номера и прочее, без чего такой шаблон будет выглядеть подозрительно.
А мог и с любого форума, где у меня почта на muzychenko.net и имя на русском. А еще мог из слитой базы данных загранпаспортов, водительских удостоверений и прочего. Дальше будем гадать, или уже хватит?
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Но насторожило совершенно непонятное явление: если в гуглопоиске набрать "virtual audio cable", то в позиции vac.muzychenko.net (она обычно идет второй-четвертой) почему-то вижу имя по-русски (не транслитерация с латиницы, а правильное русскоязычное написание), хотя ни на этом поддомене, ни на корневом домене нет ни одной страницы с русскоязычным написанием (они есть только на других поддоменах).
Проверил в хроме — воспроизводится:
Проверил, не влияет ли на это язык интерфейса хрома (был русский) — нет, не влияет. Скриншот снят под настройкой "English".
TW>>https://software.muzychenko.net/ru/
TW>>А тут то вы на русском TW>>Вполне мог и отсюда взять
ЕМ>А мог и с любого форума, где у меня почта на muzychenko.net и имя на русском. А еще мог из слитой базы данных загранпаспортов, водительских удостоверений и прочего. Дальше будем гадать, или уже хватит?
ЕМ>>хотя ни на этом поддомене, ни на корневом домене нет ни одной страницы с русскоязычным написанием (они есть только на других поддоменах)
Он ваш сайт воспринимает целиком, а не как набор отдельных независимых поддоменов
Я к чему. У вас основная страница пустая
Можно там попробовать сделать описание Вас и ваших программ на английском
Может он его подцепит
Здравствуйте, TailWind, Вы писали:
TW>Ладно напишу, хотя это и капитан очевидность
Не льстите себе, это всего лишь одно из частных мнений, притом далеко не самое компетентное.
TW>Здесь изначально ошибка проектирования сайта
Это вообще спорное утверждение, даже вне контекста обсуждаемого вопроса.
TW>На этом форуме часто всплывают темы: TW>- делать отдельный сайт под программу или сайт компании с программами TW>- делать отдельный сайт под каждый язык или все языки на одном
И однозначного вывода, который бы сколько-нибудь надежно работал, так и не случилось. Если посмотрите на структуры популярных сайтов, сразу увидите, что они применяют совершенно разные подходы, но это не мешает им быть популярными.
TW>если бы вы основной домен сделали = название компании
Поскольку у меня нет компании, то и основной домен — "фамильный".
TW>И название компании было бы запоминающимся и раскрученным TW>Тогда бы ваш VAC отличали от VAC конкурента в поиске по названию компании
Если бы все было так просто, законодательство об охране товарных знаков или не родилось бы, или давно усохло.
TW>которое всегда было бы латиницей
Внезапно, еще месяц назад мое имя там было латиницей, но это не мешало конкуренту путать пользователей.
TW>Но различать продукты по имени владельца, да которое ещё фиг запомнишь
Их и не нужно различать по имени владельца. Исходно был продукт с определенным названием, по которому его прекрасно узнавали. За время его существования не раз появлялись схожие продукты, но их разработчики вели себя разумно, и выбирали собственные названия, поэтому никаких коллизий не было. Исключение — какая-то мутная китайская контора, которая некоторое время пыталась "оседлать" популярное название, но в итоге куда-то сгинула. А потом появился неадекватный француз, который начал везде спамить своими продуктами, используя название вроде бы как синоним, но так, что продукты было легко спутать. По уму, уже тогда нужно было регистрировать товарный знак, и даже начал этим заниматься, но все вокруг утверждали, что это неимоверно сложно и дорого, а разобраться самому руки не дошли. А когда все же зарегистрировал, француз успел засрать вообще все, до чего дотянулся, и без судебных тяжб проблему уже не решить. Заниматься же тяжбами с российской юрисдикцией — такое себе.
TW>Теперь либо всё переделывать
Нет никакого смысла переделывать что-либо вокруг сайта продукта.
TW>Либо личный бренд раскручивать. Мол VAC от Евгения Музыченко (как полное имя программы). И только этот правильный
Достаточно тупо засрать все ссылками, но уже на себя. Но у меня на это нет ни времени, ни желания.
TW>VAC это уже не ваш бренд. А название класса программ
Да, это "описательный знак". И я совершенно не против его использования в соответствии с положениями закона (например, "virtual audio cable like VB-Cable or VAC"). Реальную путаницу вызывает только использование "в качестве имени", когда словосочетание выделяется заглавными буквами и непосредственно связывается с другим продуктом/брендом — это как раз прямо запрещено законом. Адекватные люди это понимают, и не злоупотребляют, а если ошибаются, то я прошу изменить текст, и они его меняют. Ну а француз просто неадекватен, как личность, поэтому с ним — только судиться. Может, и сподоблюсь когда. Чем позже — тем дольше срок злоупотребления, тем больший объем недополученной прибыли можно будет предъявить.
Здравствуйте, Aquilaware, Вы писали:
ЕМ>>А это тогда что?
A>Это схема для продукта. А вот это — это уже схема для вебсайта.
А, понял. Когда Вы упомянули "https://schema.org/WebSite", я подумал, что этот URL указывается в @Context.
A>Вы не можете брать атрибуты разных схем и просто так запихивать их в одну "общую" схему
У меня используется схема для продукта, поскольку поддомен выделен под один определенный продукт.
Здравствуйте, Sinclair, Вы писали:
S>Проверил в хроме — воспроизводится:
Спасибо. Я тоже проверял всяко-разно, это явно проделки "новых алгоритмов".
S>Проверил, не влияет ли на это язык интерфейса хрома (был русский) — нет, не влияет. Скриншот снят под настройкой "English".
Анало-гично.
S>там тоже написано Евгений Музыченко кириллицей.
Такая же фигня.
S>Попробуйте выполнить эту инструкцию — возможно, сможете сделать своё имя латиницей.
Я пока в упор не пойму, как должна выглядеть эта Knowledge Panel, и где там должно быть Suggest Edits.
Здравствуйте, TailWind, Вы писали:
TW>Он ваш сайт воспринимает целиком, а не как набор отдельных независимых поддоменов
Ну с чего Вы взяли такую очевидную глупость? Здесь уже достаточно написали про Knowledge Graph — это оно.
TW>У вас основная страница пустая TW>Можно там попробовать сделать описание Вас и ваших программ на английском
Можно, но не нужно такого бессмысленного шаманства.
ЕМ>Если бы все было так просто, законодательство об охране товарных знаков или не родилось бы, или давно усохло.
Вы всё равно не будите судиться, не смешите
Гугл считает "virtual audio cable" классом программ, а не вашим товарным знаком
Вы отрицаете проблему. И способа решить у вас её нет
У меня знакомый предприниматель в одно время тоже начал жаловаться, что появился конкурент, который заспамил весь гугл ссылками на себя. Тоже говорил что он неадекватный и ведёт не честную игру. А потом у него доходы упали в два раза
Здравствуйте, TailWind, Вы писали:
TW>Вы всё равно не будите судиться
Если посчитаю это выгодным — буду, почему нет.
TW>Гугл считает "virtual audio cable" классом программы
Гугл считает это все текстом, в котором он иногда понимает какой-то смысл, не более того.
TW>Вы отрицаете проблему.
Если Вы почитаете переписку выше, то сможете увидеть, что проблему я признаю, и доступные на данный момент действия сделал. Отрицаю я исключительно Вашу очевидно надуманную трактовку.
TW>У меня знакомый предприниматель в одно время тоже начал жаловаться, что появился конкурент, который заспамил весь гугл ссылками на себя. Тоже говорил что он неадекватный и ведёт не честную игру. А потом у него доходы упали в два раза
У меня они падали и в три раза. Потом росли в пять раз. Потом снова падали и снова росли. Это зависит далеко не только от количества ссылок.
Здравствуйте, TailWind, Вы писали:
TW>Почему анализа? Интуиции ))
Интуиция, как известно, основана на информации, а у Вас — чистой воды апофения.
TW>Вы выезжали только за счёт отсутствия конкурентов TW>Теперь всё изменилось
Оно изменилось десять лет назад, если Вы не в курсе. А обсуждаемая проблема возникла не более месяца назад.
ЕМ>Интуиция, как известно, основана на информации, а у Вас — чистой воды апофения.
Спасибо за новый интересный термин
Хорошая вещь судя по описанию, если уметь ей пользоваться, то есть проверять предположения экспериментом
Какая разница, что они взялись из воздуха, если одно из них рано или поздно сработает. У меня всегда срабатывает
Вы же идёте в отказ и не хотите ничего пробовать и настраивать до идеальности
Это можно понять: работает, не трогай
Я сначала разозлился на бранное слово, потом почитал описание, помозговал. Да именно так у меня мышление и работает
ЕМ>С таким подходом Вы рискуете тратить много ресурсов на то, что отчего-то показалось дельным, но в действительности не дает значимого эффекта.
Как ни странно. Мне это нравится
В сложных задачах, когда нет "документации" и нужно взломать, найти как работает, разобраться в чём-то, попробовать так и сяк, а иногда и наугад. Увидеть случайно хвост решения в несвязных данных и уцепиться за него. Апофения даёт отличный результат
И кстати да, интересно. У меня такое часто случалось. Действительно я тратил много времени в жизни на вещи, не давшие мне результата
Здравствуйте, TailWind, Вы писали:
TW>В сложных задачах, когда нет "документации" и нужно взломать, найти как работает, разобраться в чём-то, попробовать так и сяк, а иногда и наугад. Увидеть случайно хвост решения в несвязных данных и уцепиться за него. Апофения даёт отличный результат
Это ни разу не апофения, а вполне себе годные методы "последовательного", "случайного" и "логического" тыка. Но работают они только с хорошо контролируемыми объектами, на которые Вы можете воздействовать разными способами, по возможности отсекая ненужные воздействия, и достаточно эффективно отслеживая результаты.
Апофения — это самоубеждение (а затем и убеждение других) в том, что в некой совокупности явлений имеется некий скрытый смысл, наличие которого невозможно сколько-нибудь надежно проверить. Так люди "видят" всяческие "знаки судьбы", "намеки мироздания" и т.п.
В применении к упомянутым Вами задачам это выглядит примерно так: "В прошлый раз ошибка произошла, когда я пил за компьютером кофе, а в позапрошлый — когда пил сок. От других я слышал, что в таких случаях у них иногда начинали глючить и отказывали клавиатуры и ноутбуки. Значит, для устранения ошибки нужно перестать пить за компьютером". А если вдруг отказ от такого питья случайно совпадет с исчезновением ошибки, то велика вероятность появления нового псевдоубеждения.
TW>я тратил много времени в жизни на вещи, не давшие мне результата
Я тоже. Но я не вижу смысла тратить заметное количество ресурсов на то, что не приносит результата со сравнимой вероятностью.
В применении к обсуждаемому вопросу идея делать что-то как с базовым доменом, так и с другими поддоменами выглядит чистой воды шаманством, направленным на ублаготворение духов предков.
ЕМ>В применении к обсуждаемому вопросу идея делать что-то как с базовым доменом, так и с другими поддоменами выглядит чистой воды шаманством, направленным на ублаготворение духов предков.
У вас тут серьёзный косяк. Странно что вы это отрицаете
Как мне в гугле найти вас, а не вашего конкурента?
Надо добавить ещё одно ключевое слово в запрос
Думаете кто-то из США сможет запомнить ваше ФИО? Нет
То что вы не захотите с этим ничего делать, я вам сразу так и написал
> и без судебных тяжб проблему уже не решить. Заниматься же тяжбами с российской юрисдикцией — такое себе.
Может юриста спросить? Вдруг хороше составленное письмо наезд от Юриста завтавит их передумать? Могу Игоря Моцного например посоветовать, может не так дорого и выйдет.
TW>Он ваш сайт воспринимает целиком, а не как набор отдельных независимых поддоменов
TW>Я к чему. У вас основная страница пустая TW>Можно там попробовать сделать описание Вас и ваших программ на английском TW>Может он его подцепит
Присоеденюсь, уже лет 5 наверно soft — это YMYL тематика, в ней обязательны EAT факторы, а именно, информации о компании (ИП и виртуальный бренд подойдет).
Обязательно ХОРОШАЯ about page, которая не испугает Асессора. С микроразметкой, организация, same as. С адресом, картой, списком ключевых сотрудников (себя хотя бы и жены) со ссылками на Linked in, дипломами, легальными документами компании, теелфонами, нужен еще валидированный GMB (он должен быть). Очень желательно ссылки и акнивность на trustpilot и прочие G2. Иначе говорят весь сайт получит штраф по YMYL.
Здравствуйте, TailWind, Вы писали:
ЕМ>>В применении к обсуждаемому вопросу идея делать что-то как с базовым доменом, так и с другими поддоменами выглядит чистой воды шаманством
TW>У вас тут серьёзный косяк.
Не вижу ни малейших косяков в организации поддоменов. Никаких содержательных аргументов, с которыми можно было бы работать целенаправленно, Вы в этом плане не приводили, и от того, что Вы еще пять или десять раз повторите свои домыслы на этот счет, в моем отношении ничто не изменится.
TW>Как мне в гугле найти вас, а не вашего конкурента?
Если Вы знаете, кто я такой, и Вам необходимо найти конкретно меня, то это не составит труда. Если же Вам необходимо найти продукт, то Вы и ищете по реквизитам продукта — названию, функциональности, свойствам и прочему. При таком поиске, как тут уже было показано, мой продукт будет на втором или первом местах — даже если не на моем сайте, то в Википедии и на "файлопомойках", где есть ссылки на меня и мой сайт.
Упираться в то, чтобы привлечь побольше самых тупых пользователей, которые всегда идут только по первой ссылке в поисковой выдаче, не рассматривая даже вторую-третью, я не хочу (уже объяснял, почему). А со случаями публикации текстов, в которых рядом с названием моего продукта идут ссылки на сайт/продукт конкурента, я вполне успешно работаю.
TW>Надо добавить ещё одно ключевое слово в запрос
Или просмотреть хотя бы три-пять первых позиций выдачи. Те, кто не может или не хочет этого делать, не являются моими приоритетными клиентами.
TW>Думаете кто-то из США сможет запомнить ваше ФИО? Нет
Как показывает практика, многие могут и запоминают, указывая принадлежность продукта в своих постах.
TW>То что вы не захотите с этим ничего делать, я вам сразу так и написал
С тем, чтобы по "описательному" названию быть всегда в первой позиции выдачи — не хочу, ибо не вижу смысла. А с тем, чтобы мой продукт меньше путали с другими — могу, хочу и делаю. Чего тут еще непонятного?
Здравствуйте, eustin, Вы писали:
E>Может юриста спросить? Вдруг хороше составленное письмо наезд от Юриста завтавит их передумать?
Будь конкурент российским, я б и сам написал письмо не хуже большинства юристов. С французскими все не так просто — у них тут неадекватная либеральность одних положений закона соседствует с неадекватной же зарегулированностью других. А местные юристы (так же, как и штатовские) любят брать неадекватные гонорары просто за "участие", не гарантируя вообще никаких результатов.
Здравствуйте, eustin, Вы писали:
E>С микроразметкой, организация, same as. С адресом, картой, списком ключевых сотрудников (себя хотя бы и жены) со ссылками на Linked in, дипломами, легальными документами компании, теелфонами
Вы ИП? Уже опубликовали на сайте свой домашний адрес и личный телефон? Отвечаете на все звонки не пойми от кого?
E>говорят весь сайт получит штраф по YMYL.
ЕМ>Вы ИП? Уже опубликовали на сайте свой домашний адрес и личный телефон? Отвечаете на все звонки не пойми от кого?
ИП в том числе есть. Раньше на сайте были реквизиты российского ИП + фото офиса, подтвержденного в GMB. Телефон не российский с автоответчиком.
Написано, что телефон не для саппорта. Домашний адрес с привязкой к GMB тоже разместил бы, имхо лучше чем ничего.
E>>говорят весь сайт получит штраф по YMYL.
ЕМ>Еще говорят, что кур доят...
Говорят я имею в виду платный аудит от зарегистрированного Асессора Гугла с доступом к внутренним документом гугла))
(если конечно можно ему верить, но я поверил по результатам и ссылкам на рекомендации)
И про YMYL говорят многие и лет 10 уже) Врут?
Здравствуйте, eustin, Вы писали:
E>ИП в том числе есть. Раньше на сайте были реквизиты российского ИП + фото офиса, подтвержденного в GMB. Телефон не российский с автоответчиком. E>Написано, что телефон не для саппорта. Домашний адрес с привязкой к GMB тоже разместил бы, имхо лучше чем ничего.
Зачем это для софтверного бизнеса? Тем более как у вас — есть телефон, но туда нельзя позвонить. Уверен, придти по ардесу — аналогично. Или к вам можно вот туда придти и купить лицензию в оффлайне?
JPB>Зачем это для софтверного бизнеса? Тем более как у вас — есть телефон, но туда нельзя позвонить. Уверен, придти по ардесу — аналогично. Или к вам можно вот туда придти и купить лицензию в оффлайне?
Я же писал зачем) YMYL, EAT. GMB вроде как один из самых важных источников для него для Гугла, не? Откуда я взял информацию я тоже написал. Не понял в чем вопрос)
ЕМ>Про сам YMYL, может, и не врут. Но то, что Вы тут написали в применении к позициям, с реальностью почти не соотносится.
Я писал, на случай, если есть только ИП и если нет реального офиса и телефона что делать, чтобы зарегать и подтвердить GMB. Я не писал, что у нас их нет и что я так сделал)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но тут многие продают через PP, и в последнее время никто не жаловался.
буквально неделю назад с поддержкой переписывался по этому вопросу
из-за кривой 3DS у пользователей страничка тупо подвисает
сейчас доля PayPal почти 70%, хотя раньше 70% было по картам
Здравствуйте, Aquilaware, Вы писали:
A>Схемы WebSite и SoftwareApplication — это две разные схемы со своими наборами атрибутов, но они обе могут сосуществовать на одной странице
Хочу сделать общую схему Person, и указывать ее в Author/Publisher/Provider в WebSite и SoftwareApplication, но не могу понять, как. Поиск по ключевым словам вываливает тонны шлака — такое ощущение, что бОльшую часть генерит ИИ.
Как правильно связать схемы между собой, если они в заголовке на одной странице? А если на разных страницах?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Хочу сделать общую схему Person, и указывать ее в Author/Publisher/Provider в WebSite и SoftwareApplication, но не могу понять, как.
Лучше используйте Organization. Person для коммерции кусается такими проблемами как у ваc, плюс ко всему не масштабируется со временем (не продаётся, не передаётся по наследству, и т.д.). Попробуйте придумать название вашей торговой марки и используйте её в качестве имени организации. Если хотите сохранить ассоциативность с тем, как продукт продвигался ранее, можете взять вашу фамилию в качестве имени организации.
ЕМ>Как правильно связать схемы между собой, если они в заголовке на одной странице? А если на разных страницах?
Здравствуйте, Aquilaware, Вы писали:
A>Лучше используйте Organization. Person для коммерции кусается такими проблемами как у ваc
Точно кусается, или это лишь поверье, вроде того, что софт с доменов в зоне .ru продается (по крайней мере, до 2022-го) хуже, чем с доменов в зоне .com?
A>не масштабируется со временем (не продаётся, не передаётся по наследству, и т.д.).
Как тогда продается продукт отдельно от компании? Не думаю, что это так важно именно здесь.
A>Попробуйте придумать название вашей торговой марки и используйте её в качестве имени организации.
Товарный знак и называется Virtual Audio Cable.
A>Если хотите сохранить ассоциативность с тем, как продукт продвигался ранее, можете взять вашу фамилию в качестве имени организации.
Это действительно даст ощутимый эффект? Что-то известно о наличии фильтров/ранжирования на этот счет?
A>Есть 3 способа (массив, граф, 1 script тег на 1 схему): https://stackoverflow.com/a/48295719
Спасибо, мне больше подходит несколько тэгов script, так как я их вставляю из отдельных файлов через #include.
Схемы WebSite и SoftwareApplication точно должны быть только в корневых страницах? А то у меня, по сути, весь поддомен для одного продукта, и все страницы сайта описывают одно и то же приложение, и лежат в одном каталоге. Как поисковик определит, что схема, полученная с корневой страницы index.htm, применима ко всем страницам в том же каталоге?
A>Если схемы на разных страницах, то имеет смысл использовать @id
Я правильно пониманию, что основная часть URL, указанного в @id — это реальный URL страницы, на которой находится указанная схема, а anchor (часть после #), если она есть, идентифицирует различные схемы в пределах одной страницы?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это действительно даст ощутимый эффект? Что-то известно о наличии фильтров/ранжирования на этот счет?
Эффект лишь в том, что вы отвязываете продукт от себя-одиночки и привязываете его к себе-компании. У комании преимущество в том, что там теоретически могут работать несколько людей. Многие начинающие возмущенно упираются в саму возможность такого развития событий, но время потом наказывает. Как наказывает? Когда продукт выстреливает и, например, появляются сотрудники, интернет всё равно будет помнить всё и рисовать ваше имя одиночки как производителя продукта, даже тогда, когда вы уже стали компанией в, например, 10 человек. Фильтры и ранжирование тут не причем и на них этот аспект особо не влияет. Но влияет на ваших существующих и новых клиентов, так как им довольно тяжело переносить каждую очередную смену идентичности.
ЕМ>Схемы WebSite и SoftwareApplication точно должны быть только в корневых страницах?
В спецификации явно говорится, что только в корневой.
ЕМ>А то у меня, по сути, весь поддомен для одного продукта, и все страницы сайта описывают одно и то же приложение, и лежат в одном каталоге. Как поисковик определит, что схема, полученная с корневой страницы index.htm, применима ко всем страницам в том же каталоге?
og:site_name задается для каждой страницы сайта как раз с этой целью.
ЕМ>Я правильно пониманию, что основная часть URL, указанного в @id — это реальный URL страницы, на которой находится указанная схема, а anchor (часть после #), если она есть, идентифицирует различные схемы в пределах одной страницы?
Да. @id на самом деле — это URI, и в спецификации говорится о том, что при попытке доступа по этому URI должна возвращаться сама схема на который ссылается @id: https://www.w3.org/TR/json-ld/#node-identifiers
В спецификации дается такой пример: http://me.markus-lanthaler.com/. Как видим, там чистый JSON, причем HTTP заговолок Content-Type имеет значение application/ld+json, что видно тут: https://websniffer.com/?url=http://me.markus-lanthaler.com/. HTML со script тегами тоже работает. Главное чтобы @id указывал на то место, где можно получить схему. В этом случае, часть после # идентифицирует различные схемы в пределах одной страницы.
Если бы это делал я, то я бы хранил схемы в отдельных JSON файлах — один файл на одну схему, в подпапке сайта или вообше на отдельном сайте для схем, например, schemas.muzychenko.net. Тогда у каждого файла был бы свой уникальный URI, без якорей, и попытка доступа к файлу возвращала бы схему с HTTP заговолком Content-Type = application/ld+json, как в спецификации. Я предпочитаю такой способ больше, потому что с веб-страниц тогда снимается обязанность публикации содержимого самих схем, что позволяет отделить зерна от плевел. Веб-страницы тогда просто ссылаются на готовые схемы по @id, которые уже где-то хранятся отдельно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я правильно пониманию, что основная часть URL, указанного в @id — это реальный URL страницы, на которой находится указанная схема, а anchor (часть после #), если она есть, идентифицирует различные схемы в пределах одной страницы?
Здравствуйте, Aquilaware, Вы писали:
A>Эффект лишь в том, что вы отвязываете продукт от себя-одиночки и привязываете его к себе-компании.
Сомневаюсь, чтобы это давало сколько-нибудь ощутимый эффект на уровне поиска. Привязка к сайту выглядит куда более явной, но обычно поиск не страдает при переносе продукта с сайта на сайт, или страдает недолго.
A>Как наказывает? Когда продукт выстреливает и, например, появляются сотрудники, интернет всё равно будет помнить всё и рисовать ваше имя одиночки как производителя продукта, даже тогда, когда вы уже стали компанией в, например, 10 человек.
Даже если эта память в более-менее явном виде просуществует полгода, она не окажет значимого влияния. У Вас есть конкретные примеры явных неудач в таких сценариях, или это все теория и умозрительные рассуждения?
A>влияет на ваших существующих и новых клиентов, так как им довольно тяжело переносить каждую очередную смену идентичности.
Если тяжело, то зачем компании проводят ребрендинги?
Да и ассоциация с именем/названием тоже выглядит натяжкой. Допустим, китайцы основали компанию, назвали ее по-китайски, она стала популярной в Китае, для нее придумали название на латинице и вывели на международный рынок. Покупатели запомнили ее под этим названием, и тут гугл, анализируя массивы данных, начинает выдавать американцам ее родное название вместо латинизированного. Как в этом случае спасет Organization вместо Person?
A>я бы хранил схемы в отдельных JSON файлах — один файл на одну схему, в подпапке сайта или вообше на отдельном сайте для схем
Выглядит красиво, но увеличивает количество запросов.
Здравствуйте, Aquilaware, Вы писали:
ЕМ>>Схемы WebSite и SoftwareApplication точно должны быть только в корневых страницах?
A>В спецификации явно говорится, что только в корневой.
Здесь получается какой-то косяк. У меня, как и на многих сайтах, реализованы locale-adaptive pages: запрос к корню автоматически перенаправляется в /en/ (пока — безусловно, так как других языков еще нет). Из /en/ отдаются и WebSite, и SoftwareApplication. Когда предлагаю гуглу протестировать хоть голое имя домена, хоть с /en/, он находит там только SoftwareApplication, хотя в тексте страницы видно, что он получил и то, и другое.
То есть, с попаданием в нужный раздел проблем нет. А как объяснить гуглу, что нужно либо использовать схему из /en/, либо добыть ее непосредственно из корня (например, через index.htm)?
А если отключить для гуглобота перенаправление в /en/, то что ему отдавать из корня, чтоб он не сошел с ума?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здесь получается какой-то косяк. У меня, как и на многих сайтах, реализованы locale-adaptive pages: запрос к корню автоматически перенаправляется в /en/ (пока — безусловно, так как других языков еще нет). Из /en/ отдаются и WebSite, и SoftwareApplication. Когда предлагаю гуглу протестировать хоть голое имя домена, хоть с /en/, он находит там только SoftwareApplication, хотя в тексте страницы видно, что он получил и то, и другое.
Есть идея: отдавать на корневой странице https://vac.muzychenko.net/ адаптивное перенаправление на нужную локаль, но вместо этого содержимого:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://vac.muzychenko.net/en/">here</a>.</p>
</body></html>
отдавать такое же, но с нужной схемой WebSite. А из /en/ WebSite не отдавать, а только SoftwareApplication.
Я не уверен в этом приёме, но возможно это поможет преодолеть дилемму, связанную с тем, что cхема WebSite должна присутствововать в самом корне домена, чтобы поисковики могли видеть её. Интересно, получится ли вам заставить их видеть эту схему?
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Евгений Музыченко, Вы писали:
A>отдавать такое же, но с нужной схемой WebSite. А из /en/ WebSite не отдавать
Попробовал пока проделать это с общим софтовым сайтом. Сперва добавил в корневую страницу http-equiv/refresh с нулевым временем ожидания, но при открывании в браузере оно заметно моргает, и Rich Result Test по-прежнему лезет в /en/, так что вернул перенаправление в /en/ через RewriteRule, но с исключением для гуглосервисов.
Потом обнаружил, что Rich Result Test, хоть и говорит "Testing Live URL", фактически тестирует свою индексированную копию — я и по логам не вижу запросов в эти моменты, и по результату видно, что тестируется не то, что отдает сервер прямо сейчас. Поэтому пока не знаю, как оно обрабатывает http-equiv/refresh — может, и не переходит само.
Но после того, как корень сайта проиндексировался, там по прежнему No rich results detected, хотя в Tested page — HTML видно, что схема WebSite отдается. Чего ему не хватает на этот раз?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Попробовал пока проделать это с общим софтовым сайтом.
Поисковые роботы очень не любят трюки с перенаправлениеми в зависимости от юзер агента. А http-equiv/refresh они воспринимают как обычное перенаправление, поэтому это тоже работать не будет.
Использование адаптивного ответа со схемой и перенаправлением мне пока что видится одним из потенциально работающих варинтом. Но опять же, робота интересуют только конечная страница, поэтому он может схему из ответа с перенаправлением и не увидеть. Возникает классическая проблема курицы и яйца.
Здравствуйте, Aquilaware, Вы писали:
A>Поисковые роботы очень не любят трюки с перенаправлениеми в зависимости от юзер агента.
Чтобы не любить, они это должны как-то обнаружить — например, ходить с разным user-agent. Но тот же гуглобот всегда ходит с одинаковым, разве что для проверки он старательно маскируется под обычного юзера, и ходит всегда в другое время (рядом с запросами от гуглобота я не вижу обычных запросов туда же). Да и зачем бы это им?
A>А http-equiv/refresh они воспринимают как обычное перенаправление, поэтому это тоже работать не будет.
По идее, это неправильно. Если интервал до обновления задан, скажем, в минуту, то большинство юзеров может и не узнать, что перенаправление там вообще есть. То есть, должен быть некий порог, а вот какой он — вопрос.
A>Использование адаптивного ответа со схемой и перенаправлением мне пока что видится одним из потенциально работающих варинтом. Но опять же, робота интересуют только конечная страница, поэтому он может схему из ответа с перенаправлением и не увидеть.
Пока он ее не видит даже в ответе без перенаправления. А почему — не пойму.
Здравствуйте, Aquilaware, Вы писали:
A>робота интересуют только конечная страница, поэтому он может схему из ответа с перенаправлением и не увидеть.
У робота явно что-то не так с анализатором. Корневая страница уже несколько дней лежит в кэше гугла, тестер показывает схему в ее содержимом, но никаких структурных элементов не находит. Перенаправление через http-equiv там закомментарено, сервер перенаправляет через RewriteRule, кроме запросов от поисковых ботов. Если бы перенаправление сработало, когда приходил бот, в содержимом была бы страница из /en/ — она совершенно другая, и схемы там нет. Мистика какая-то.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Самое смешное — оказалось, что гугель ее не поддерживает.
На мой взгляд, не стоит полагаться на подобные списки поддерживаемых\не поддерживаемых данных. Во-первых, всё меняется со временем. Во-вторых, очень многие метки и индикаторы поисковиками получаются из-под полы и без лишней разгласки точного поведения для широкой публики. А пишут они эти публичные отписки только чтобы охладить гонку между котами и мышами (SEO-манипуляции против настоящего контента).
Здравствуйте, Aquilaware, Вы писали:
A>не стоит полагаться на подобные списки поддерживаемых\не поддерживаемых данных.
Ну я ж писал, что гугловский Rich Result Test не находит схемы WebSite в корне. А SoftwareApplication — находит.
A>очень многие метки и индикаторы поисковиками получаются из-под полы и без лишней разгласки точного поведения для широкой публики
Тогда мы снова возвращаемся к тому, ради чего я родил эту тему. Слава богу, кириллица из выдачи пропала еще с месяц назад, но связано ли это с моими манипуляциями — хз. А если нет возможности получить обратную связь, то какой смысл возиться?
В общем, как всегда, мутно.
