Здравствуйте, 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 они воспринимают как обычное перенаправление, поэтому это тоже работать не будет.
Использование адаптивного ответа со схемой и перенаправлением мне пока что видится одним из потенциально работающих варинтом. Но опять же, робота интересуют только конечная страница, поэтому он может схему из ответа с перенаправлением и не увидеть. Возникает классическая проблема курицы и яйца.
Отвечаете на все звонки не пойми от кого? 
