Статистика в общем верная. Но если у вас на JS реализована значимая функциональность, а не какие-то "украшения", то имеет смысл ее дублировать другими средствами (на стороне сервера). Речь не только о том, есть (поддержка) JS или нет, но и о наличии необходимых возможностей JS, например Fetch API или History API.
На других доменах, наверное, были другие сайты со своими страницами, т.е. своими адресами и содержимым. Тогда шаблонная переадресация - это неправильно. Если есть страницы со схожим содержимым (с такими же или другими адресами), можно сделать отдельную переадресацию для каждой страницы (/a -> /b, /c -> /d, etc.). Если сайты были совсем другими, лучше вовсе ничего не делать или в крайнем случае только с главной делать переадресацию. Я бы скорее всего оставил старые сайты с нужными ссылками или просто припарковал, если на доменах "ничего" не было. Про парковку и разные схемы переадресации можно прочитать здесь.
У CF есть свои инструменты переадресации, но по крайне раньше были недостатки.
serval#: Конкретно мой домен может резко подорожать или вся доменная зона подорожает?
И то, и то, как выше написали, если домен "красивый" или короткий.
Также от регистратуры, т.е. владельца зоны зависит. Есть вполне адекватные регистратуры, например Radix и Identity Digital (ID). С ними пока не было серьезных проблем по цене и т.п.
Kaavain#: Во все. Про 100 я написал потому, что реально оцениваю свои силы, больше руками написать текстов это тяжело.
Тогда делайте полную копию базы данных пунктов выдачи/базу данных всех населенных пунктов. Упомянутая компания работает более чем в 500 населенных пунктах РФ, насколько знаю. Вариативность использования шаблонного текста и вручную написанного текста сделать легко. Причем шаблон можно использовать не динамически, так что при выводе никакой вариативности не будет.
Шаблонные тексты можно не "скармливать" ПС. Но, повторяю, адреса у страниц таких населенных пунктов тоже должны быть уникальными. При необходимости формат их адресов можно сделать отличным от формата адресов страниц с уникальными текстами. Либо для разных типов страниц можно вариативно выводить теги/HTTP-заголовки, предназначенные для ботов ПС.
webinfo#: У меня смутное подозрение, что речь не о том, откуда продали, а о том, куда продали.
Как я понял, автор продает не во все населенные пункты, где есть пункты выдачи транспортной компании (это довольно распространенная практика). Иначе число 100 - слишком большая условность. Он вроде бы писал про крупные города.
Kaavain#: Нене, я только лишь угодить говнюку-яндексу. Кто УЖЕ нашел мой сайт, тот уже все, пожизни мой. И другим объяснит.
Адресная строка - по-прежнему один из основных источников информации для поисковых систем (через распространение ссылок пользователями).
Kaavain#: Но тут я понял, что каждое обращение к ней - это запросы по API, зачем так мучить доставщиков?
Разумный вопрос. Нужно продублировать базу данных пунктов выдачи (и поддерживать ее в актуальном состоянии). Она же будет использоваться для формирования соответствующих страниц на вашем сайте. Или хотя бы составить базу данных населенных пунктов, в которых вы осуществляете продажи (а уже со страниц населенных пунктов выполнять обращения к стороннему API).
Автор и про изменение адреса на JS спрашивал. Читай внимательнее (концовка первого сообщения). Задача решается комплексно. А вы на вторую половину решения "наплевали".
Ссылка на History API - это верно. Хорошая практика заключается в том, чтобы при любом "существенном" изменении содержимого на JS менять адрес динамически. Но это должно подкрепляться и выводом соответствующего содержимого при независимом запросе по этому адресу.
webinfo, вообще странно по нынешним меркам наблюдать, как информацию по History API называют "бессмысленной галиматьей". Сразу возникает ощущение, что кто-то "отстал от жизни" 😉
Правильно ли это?
На других доменах, наверное, были другие сайты со своими страницами, т.е. своими адресами и содержимым. Тогда шаблонная переадресация - это неправильно. Если есть страницы со схожим содержимым (с такими же или другими адресами), можно сделать отдельную переадресацию для каждой страницы (/a -> /b, /c -> /d, etc.). Если сайты были совсем другими, лучше вовсе ничего не делать или в крайнем случае только с главной делать переадресацию. Я бы скорее всего оставил старые сайты с нужными ссылками или просто припарковал, если на доменах "ничего" не было. Про парковку и разные схемы переадресации можно прочитать здесь.
У CF есть свои инструменты переадресации, но по крайне раньше были недостатки.
Конкретно мой домен может резко подорожать или вся доменная зона подорожает?
И то, и то, как выше написали, если домен "красивый" или короткий.
Также от регистратуры, т.е. владельца зоны зависит. Есть вполне адекватные регистратуры, например Radix и Identity Digital (ID). С ними пока не было серьезных проблем по цене и т.п.
Во все. Про 100 я написал потому, что реально оцениваю свои силы, больше руками написать текстов это тяжело.
Тогда делайте полную копию базы данных пунктов выдачи/базу данных всех населенных пунктов. Упомянутая компания работает более чем в 500 населенных пунктах РФ, насколько знаю. Вариативность использования шаблонного текста и вручную написанного текста сделать легко. Причем шаблон можно использовать не динамически, так что при выводе никакой вариативности не будет.
Шаблонные тексты можно не "скармливать" ПС. Но, повторяю, адреса у страниц таких населенных пунктов тоже должны быть уникальными. При необходимости формат их адресов можно сделать отличным от формата адресов страниц с уникальными текстами. Либо для разных типов страниц можно вариативно выводить теги/HTTP-заголовки, предназначенные для ботов ПС.
У меня смутное подозрение, что речь не о том, откуда продали, а о том, куда продали.
Нене, я только лишь угодить говнюку-яндексу. Кто УЖЕ нашел мой сайт, тот уже все, пожизни мой. И другим объяснит.
Адресная строка - по-прежнему один из основных источников информации для поисковых систем (через распространение ссылок пользователями).
Но тут я понял, что каждое обращение к ней - это запросы по API, зачем так мучить доставщиков?
Разумный вопрос. Нужно продублировать базу данных пунктов выдачи (и поддерживать ее в актуальном состоянии). Она же будет использоваться для формирования соответствующих страниц на вашем сайте. Или хотя бы составить базу данных населенных пунктов, в которых вы осуществляете продажи (а уже со страниц населенных пунктов выполнять обращения к стороннему API).
Где там про "изменение адреса на JS"?
Я ж говорю: "кто-то отстал от жизни". Иначе бы вы сразу увидели комплексное решение.
Естественно, я не опровергаю и ваши советы. А то автор сейчас действительно начнет "клепать" статические страницы (html-файлы) 😀
Но при чём тут pushstate?
Автор и про изменение адреса на JS спрашивал. Читай внимательнее (концовка первого сообщения). Задача решается комплексно. А вы на вторую половину решения "наплевали".
Из ничего ругань на три страницы развели 😦
Ссылка на History API - это верно. Хорошая практика заключается в том, чтобы при любом "существенном" изменении содержимого на JS менять адрес динамически. Но это должно подкрепляться и выводом соответствующего содержимого при независимом запросе по этому адресу.
webinfo, вообще странно по нынешним меркам наблюдать, как информацию по History API называют "бессмысленной галиматьей". Сразу возникает ощущение, что кто-то "отстал от жизни" 😉
но в общем типы 2 и 4 взаимозаменяемые