Сообщение Re[7]: Снова беда с поиском :) от 15.10.2023 19:21
Изменено 15.10.2023 19:24 Aquilaware
Re[7]: Снова беда с поиском :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это действительно даст ощутимый эффект? Что-то известно о наличии фильтров/ранжирования на этот счет?
Эффект лишь в том, что вы отвязываете продукт от себя-одиночки и привязываете его к себе-компании. У комании преимущество в том, что там теоретически могут работать несколько людей. Многие начинающие возмущенно упираются в саму возможность такого развития событий, но время потом наказывает. Как наказывает? Когда продукт выстреливает и, например, появляются сотрудники, интернет всё равно будет помнить всё и рисовать ваше имя одиночки как производителя продукта, даже тогда, когда вы уже стали компанией в, например, 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, как в спецификации. Я предпочитаю такой способ больше, потому что с веб-страниц тогда снимается обязанность публикации содержимого самих схем, что позволяет отделить зерна от плевел. Веб-страницы просто ссылаются на готовые схемы, которые уже где-то отдельно хранятся.
ЕМ>Это действительно даст ощутимый эффект? Что-то известно о наличии фильтров/ранжирования на этот счет?
Эффект лишь в том, что вы отвязываете продукт от себя-одиночки и привязываете его к себе-компании. У комании преимущество в том, что там теоретически могут работать несколько людей. Многие начинающие возмущенно упираются в саму возможность такого развития событий, но время потом наказывает. Как наказывает? Когда продукт выстреливает и, например, появляются сотрудники, интернет всё равно будет помнить всё и рисовать ваше имя одиночки как производителя продукта, даже тогда, когда вы уже стали компанией в, например, 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, как в спецификации. Я предпочитаю такой способ больше, потому что с веб-страниц тогда снимается обязанность публикации содержимого самих схем, что позволяет отделить зерна от плевел. Веб-страницы просто ссылаются на готовые схемы, которые уже где-то отдельно хранятся.
Re[7]: Снова беда с поиском :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это действительно даст ощутимый эффект? Что-то известно о наличии фильтров/ранжирования на этот счет?
Эффект лишь в том, что вы отвязываете продукт от себя-одиночки и привязываете его к себе-компании. У комании преимущество в том, что там теоретически могут работать несколько людей. Многие начинающие возмущенно упираются в саму возможность такого развития событий, но время потом наказывает. Как наказывает? Когда продукт выстреливает и, например, появляются сотрудники, интернет всё равно будет помнить всё и рисовать ваше имя одиночки как производителя продукта, даже тогда, когда вы уже стали компанией в, например, 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, как в спецификации. Я предпочитаю такой способ больше, потому что с веб-страниц тогда снимается обязанность публикации содержимого самих схем, что позволяет отделить зерна от плевел. Веб-страницы тогда просто ссылаются на готовые схемы, которые уже где-то хранятся отдельно.
ЕМ>Это действительно даст ощутимый эффект? Что-то известно о наличии фильтров/ранжирования на этот счет?
Эффект лишь в том, что вы отвязываете продукт от себя-одиночки и привязываете его к себе-компании. У комании преимущество в том, что там теоретически могут работать несколько людей. Многие начинающие возмущенно упираются в саму возможность такого развития событий, но время потом наказывает. Как наказывает? Когда продукт выстреливает и, например, появляются сотрудники, интернет всё равно будет помнить всё и рисовать ваше имя одиночки как производителя продукта, даже тогда, когда вы уже стали компанией в, например, 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, как в спецификации. Я предпочитаю такой способ больше, потому что с веб-страниц тогда снимается обязанность публикации содержимого самих схем, что позволяет отделить зерна от плевел. Веб-страницы тогда просто ссылаются на готовые схемы, которые уже где-то хранятся отдельно.