Lazy Badger

Lazy Badger
Рейтинг
259
Регистрация
14.06.2017
sergv #:

Судя по тому, как вообще задан вопрос и какие данные в себе содержит - ТС не очень понимает как все работает и что (кто) отвечает за регистрацию, а что (кто) за непосредственный доступ.

И хорошо еще, если отличает домен от сайта.

suffix #:
Самый первый запрос как пойдёт ?

Неизвестно, потом что 

Lazy Badger #:
Все сервера корневой зоны отмиррорены у нас еще во времена РосННИРОСа

и откуда load-balancing отдаст и какие хинты на "." - не скажут даже всезнающие икспэрды из школоты 

suffix #:
запрос dns если регистратор в США будет несколько более медленным для российских пользователей сравнивая с местным регистратором.

Фу, товарищ хостмастер.

  • Где живут зоны домена - от регистатора совсем не зависит (если забыть про промежуточные кэши даже)
  • Все сервера корневой зоны отмиррорены у нас еще во времена РосННИРОСа

  • Нет
  • Нет
Надо хоть немноговрубаться в тему и понимать, что именно делает регистратор, где и когда

Виктор Петров #:
У вас кроме логотипа на всех страницах - пустота.

Все на месте, но такое... беспонтовое. Картиночки с хреновейшей навигацией

Kuloresov :

Сайт картиночник, но картинки, собственные уникальные, на запрос пользователя он отвечает. 

Не отвечает. Неудобен, неочевидные навигация и назначение. Законное место - дно, куда и был отправлен.

ТС, ты можешь быть хорошим рисовальщиком, но сайт - отстой из нулевых

Антоний Казанский #:

Нет на них никаких запросов, это адреса сформированные последовательностью пользовательского фильтра.

Не, не поругаемся. Прям таки уверен, что на них нет запросов? Я не видел структуру фильтров пациента, но более чем уверен, что цвет-страна происхождения-размер там есть

Антоний Казанский #:

Может быть так:

?filter=312;318;824

а может быть так:

?filter= 318;312;824

а может так:

?filter= 318;824;312

А это уже вопрос к разработчикам, не понимать разницу между комбинациями и сочетаниями и не проводить нормирование данных - это сигнальчик

Антоний Казанский #:
Это не страницы, это лишь рабочий эпизод, где будут выводиться наборные комбинации из товаров, которые есть в базе

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

x2.soft #:
остается открытым вопрос, как поступать? 

Страдать. С чего вообще, чика, недовольство?

- это не аффилиат, а просто конкуренция по ГНЗ брендовому запросу в чистом виде

- ЖК Кутузовских по стране больше 1 (только в Москве - как минимум 2), с неудачным для вас брендингом бодаться с москвичами будете постоянно в ГНЗ и они вас будут постоянно делать, потому что совершенно разные бюджеты и профессионализм исполнителей

Антоний Казанский #:
Если вы оставите открытыми для индексации, то это будут дубли

1. Это не будут дубли ни логически, ни контентно... и даже (ненужный и вредный в контексте задачи) canonical c 99% вероятности будет Яндексом пригнорирован, потому что контентно страица фильтра на категорию и нефильтра - разные

2. Закрывать страницы фильтров от индексации - идеологически неправильно, если на них есть запосы с ненулевым спросом

kustov :
Второй вариант выглядит интереснее

"Оба хуже!" (с). Самым нормальным (и требующим отдельного внимания и труда) будет вариант "2+", в котором

- всем страницам фильтров даны вменяемые и уникальные мета (ну и текст на странице - желательно)

- страницы фильтров с ненулевыми запросами на них (естественно) индексируются и имеют постоянный, не меняющийся от погоды на Марсе URL (без цифровых иднтификаторов параметров фильтра, которые могут меняться в процессе жизни),  при этом формат URL в общем-то неважен,  и  /search/?filter= и  /postelnoe-belje/iz-hlopka?filter= не принципиальны ни для людей ни для ПС (кроме момента, справедливо выше отмеченного Антонием).

Но я, по привычке "подстелить соломки от альтернативно-одаренных", избавился бы вообще в URL индексируемых (читать "нужных для бизнеса") фильтов от GET-параметров, чтобы избежать последствий от действий идиота, которы не глядя засунет в robots Disallow: /?. В битриксе, скажем, к их фильтрам есть пожелания всякие, но вот URL делают почти хорошо: просто непараметризованный URL, только к длине есть претензии, если параметров реально много

Aisamiery #:
это же официальный способ расширения

Для тех, кто не пишет код. Для тех, кто пишет, мне кацца, есть модули

Aisamiery #:
я не видел нигде OC на больших проектах

Там есть некие вопросы к масштабированию, поэтому есть тенденция миграции на больших объемах SKU на CS-Cart

Aisamiery #:
если бы стоимость была заметно ниже, то все топы сидели бы именно на ОС

А им-то зачем? ТСО выше, так и бюджеты совсем другие, нет мысла в экономии на пару процентов

Aisamiery #:
1. Там вопросов достаточно много, у меня больше вопросов к расширению, пилить php код в xml в целом очень сомнительное решение

Вольно ж вам, барин, смотреть на русский OpenCart - это как раз тот случай, когда не блоху подковали, а лом пилят японской бензопилой. В оригинале-то он - китайский (точнее - гонконгский), и там таких диких странностей сильно поменее

Aisamiery #:
я не говорю что опенкарт это плохо всегда, я лишь указал что он для небольших проектов, где команда разработки состоит из одного человека,

Я видел несколько вполне адекватных командны разработок магазинов на OC, но

- чаще всего дело не в инструменте, а в исполнителях и их РКР (по "магазы на Битрихе" ты поболее меня в теме)

- OC, как ни крути, все же на SMB ориентирован, где нет большинства замеченных тобой выше гитик, которые нужны большим и толстым корпоратам.

Ну и, по гамбургскому счету, ТСО правильного и даже удобного и прибыльного шопа на OC заметно ниже, чем альтернативного решения на ВП+Вцкоммерс или Битрих (помня, что SMB и бюджеты соотвествующие)

Всего: 3147