если контент страницы обновляется аяксом, то перемещение по history броузера мало когда будет (но иногда и будет) соответствовать реальным телодвижениям юзверя. при "назад" по history он вполне естественно попадёт на состояние страницы без всей его "аяксовской интерактивности".
итог: вы сами себя запутали. тут нужны не бразерные а свои кнопки назад/вперёд и способ хранение реальной "history" юзверя...
параметры отбора через сеcсию передаются или как? если через сессию - попробуте для эксперимента передавать сессию не через куки, а через get. и кстати, авторизация юзверя то же сбрасывается?
сайтмэпов может быть столько сколько надо, но их разделение используется для оптимизации ресурсов ботов (когда единая сайтмэп имела бы огромные размеры) и ускорения индексации сайта, а не для повторного продавливания плохо индксирующихся страниц.
хотя даже интересно, за дубли-сайтмэпы под пенальти попасть можно? ;) расскажите потом что как..
это "сложно" ? 😂 это как раз ерунда, а вот "нахрена" ответить можно только симметрично: "дохрена" причин и резонов...
попробуйте код метрики вызывать по window.onload, или в $(document).ready вставьте, если JQuery используете. метрика может слегка поругаться, но работает на 100% и в таком варианте.
хотя более приличным вариантом будет запуск скрипта метрики заведомо после отработки всех скриптов CMS, это сложнее , но не на много (надо будет, видимо, флаг какой-н создать и отслеживать по таймауту).
ну а самый лучший вариант - всё же отловить конфликт скриптов...
что ж тут непонятного, если вопрос о "переносе url" тут вообще не стоит? если такой страницы в новой структуре просто не будет, то все просто: либо честный 404 и руками удалить из индекса, что бы боты время не теряли, либо 301 на страницу самого кликабельного товара...
это как бе азбука: не нашёл nginx файл в директории - вызвал компоновщик/интерпретатор с этим URI в параметрах, тот или отработал, если контрольные суммы поменялись, или отдал кэш. тут особо мозжечок напрягать не надо ;) ну а в prodaction удовлетворительный вариант кэша уже лежит в этой папке готовенький к засосу...
ну вообщето, результаты отработки скриптов сжатия/компановки ессесно кэшируются серваком, 99.999% времени работают только скрипты контроля изменений. да и постоянный запуск этих примочек происходит только в dev варианте - для prodaction подсовывается полученный результат, уже как чистопородная статика (не требующая гзипа ко всему прочему). другое дело, что по разгильдяйству dev даже на боевом сервере может длится месяцами 😂, но и это не смертельно...
надо пробовать LESS, но это ж перелопатить не одну тысячу строк готовых заготовок CSS. хотя плюшки вырисовываются чрезвычайно вкусные, да и эти "тысячи" в резалте могут изрядно "похудеть"...
ничего не попутали? отработка интерпретатора на стороне сервера как раз и обеспечит "статичность" результата для клиента. моё имхо: как раз нагружать клиента интерпретацией не стоит по любому, а с наших серверов он и так уже получает сжатый и скомпонованный CSS. вопрос - стоит ли только ради нашего удобства запускать перед сжатием+компановкой еще и LЕSS интерпретатор.
кто использовал - тот в курсе ;) ну а для "любознательных", что уж, не жалко: Google
