Подгрузка при скроле для бота выглядит так же как если бы на каждой странице была кнопка "Дальше", которая перекидывает на следующую страницу. Собственно, там эта кнопка и есть. Когда страницу смотрит пользователь, то отслеживается сколько он недоскролил до кнопки и, скажем, на 500 пикселях скрипт запрашивает содержимое по ссылке из кнопки аяксом и вставляет ответ ниже. Серверная часть же бьется на две ветки: если запрос идет аяксом, то отдать только содержимое новостей (без шапки, сайдбара, футера); если запрос обычный, то отдать страницу целиком (для бота).
Там при покупке семейной лицензии, что на 400 руб в год дороже, вообще 5 тб дают.
Якоря там и стоят, только они не в href прописаны, а тянутся скриптом из дополнительного атрибута. Например, если посмотреть инспектором ссылку "Корпуса", то там будет data-href="#housing". Все клики по ссылкам вкладок ловятся и обрабатывается этот атрибут. На подобном трюке половина bootstrap работает. Для смены url без перезагрузки страницы гуглить "history.pushState". Скролл отлавливается обработчиком на событие и сверкой текущей позиции с положением анкора: http://jsfiddle.net/gugahoi/2ZjWP/8/
На самом деле черт его знает как оно с точки зрения SEO, весь контент (ну или просто огромная часть, я особо глубоко не вникал) там одной страницей по сути идет. Целиком грузится значительная часть сайта, а дальше куча скриптов его разруливают по адресам. Я мельком глянул список того, что они используют - ну очень много наворотов.
Имхо, если это для раздела "Контакты", то ставить карту + зарегистрировать компанию на самих картах (еще и оттуда трафик может быть неплохой).
Там же файл icons.png к скрипту идет. Бери да перерисовывай, соблюдая порядок и размер иконок 32*32. Можно и произвольного размера прикрутить, но это в JS надо лезть.
Дополню, что еще обязательно надо подключать вот это (зависит от jQuery):
<!--[if lt IE 9]> <script src="//css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script> <![endif]-->
Иначе под IE8 весь код в @media будет выполнятся вне зависимости от ширины экрана, т.е. даже на десктопе.
Если страница реально часто обновляется в динамике, например, какие-то котировки на бирже или очень активная новостная лента, то надо делать отдельную кнопку "Обновить", которая будет аяксом тянуть только обновленные данные, а не перегружать всю страницу целиком + автоообновление тем же аяксом по необходимости.
И еще, в первом сообщении ТС говорит о шаблоне для статьи =) В любом случае, для обновления страницы есть кнопка F5 + соответствующая иконка возле строки с URL - не надо изобретать велосипед.
По локализации. Я бы все поля, для которых необходима локализация вынес в отдельную таблицу: ID_Товара (уникальный, вне зависимости от источника), ID_языка, Поле1, Поле2, Поле3 и т.д.
С локализацией просто такое дело, что может понадобится, например, при отсутствии русского перевода выдавать английский. Дергать таблицы с кучей лишних данных (которые еще и без надобности дублироваться будут) в таком случае будет накладно по производительности.
Про то чтобы локализировать дополнительными полями в таблице вообще речи не должно идти - хреново масштабируется. Завтра понадобится новый язык и надо лезть колупать бекэнд (возможно, в 10 разных местах) для поддержки нового поля. Лучше уж один раз человеческую поддержку сделать и потом просто в админке добавлять новые языки.
По специфическим данным для разных источников. Тут надо знать насколько много источников и как сильно они отличаются + необходимость делать выборки по ним. Если там до десятка INT/DOUBLE полей - можно и в одну таблицу свалить, а если куча TEXT/BLOB - надо их разносить по разным таблицам обязательно.
Опять же советую смотреть на универсальность, чтобы меньше гемороя было при возможном добавлении нового источника. Например, если разница между ними гарантировано будет в нескольких мелких полях, и по этим полям не надо делать выборки (только выводить), то можно их даже в JSON запихнуть.
Добавлю о более-менее универсальном хранении дополнительных атрибутов. В таком случае их придется вынимать отдельным запросом, но гибкость хорошая + можно сверху накрутить разбитие по группам.
Нужно минимум две дополнительные таблицы:
1. attributes: attribute_id, language_id, name
2. product_attributes: product_id, attribute_id, language_id (если надо переводить значения атрибутов), value
Не суть важно какая страница. Вы можете с точки зрения юзабилити представить себе ситуацию когда пользователю понадобится перейти на ту страницу на которой он уже находится, да еще еще и прям из заголовка? Вырезать один тег, по-моему, не проблема.
http://ajaxplorer.info/
