Владлен Грачев

Является.

Объясню несколько абстрактно. С конкретными терминами определитесь сами. Предположим, у вас есть некий объект. Пусть это массив. Это сложный тип данных.

Сериализация позволяет привести этот объект к последовательности байтов (часто ее можно рассматривать как строку, созданную по определенным правилам), которую в дальнейшем можно десериализовать, то есть получить из нее исходный объект.

Для чего это нужно? Сохранить сложный объект где-либо. Например, в единственном поле БД, в сессии, в куках, просто в файле. С возможностью получить исходный объект в дальнейшем.

Или для передачи. Допустим, вы собрали данные от пользователя с некоторой формы, получив массив данных. Эти данные надо отправить на сервер. В качестве параметра запроса может выступать строка, но не массив. Поэтому перед передачей массив необходимо сериализовать.

Как использовать. Там есть и от майкрософта статьи, и вполне разжеванная от code-inside. В общем, на любой вкус.

А ваши комментарии о том, что интересует сериализация именно на C#, несколько неуместны. Очень многие термины и процессы в программировании мало изменяются от языка к языку. Различается лишь синтаксис и способы использования. Сама суть сохраняется.

В руководстве Яндекса четко расписано, что требуется для индексирования: формат ссылок и формат url для страниц с контентом. Товарищ, прокомментировавший ваш комментарий, вероятно, счел, что вы предлагаете использовать ссылки без параметра href вовсе. Такие ссылки действительно индексировать не будут. Но если использовать рекомендации поисковиков, проблем не должно быть.

Что касается пруфов, далее идут настолько пруфы, насколько это возможно..
Есть чуть более внятное описание того же самого от Яндекса, где для особо непонятливых уточнено, что иные варианты реализации могут оказаться менее приятными в плане результата.
И есть FAQ от Гугла, ибо принцип один и тот же. Там же ссылка на более подробную документацию (на английском, правда).

Вы говорите об архитектуре CMS, но, уточняя, упоминаете лишь сторону верстки (табличная и блочная верстка, версии html и css). Если дело только в этом, то вопрос, скорее, исключительно к теме оформления.

Вас действительно только фронт-энд интересует? Тогда CMS тут имеет значение небольшое. Какую тему сверстаете, такая и будет. Хоть на HTML 5, хоть на HTML 3.2.

Важное требование лишь одно — чтобы реализация подходила вам и вашей целевой аудитории. Если цель — поддерживать максимум окружений, поддержка IE5 и всяких Нетскейпов (утрирую, конечно), то надо по-старинке все (за исключением разве что таблиц). Если же целевая аудитория по большей части использует актуальные версии браузеров, то можно уже играть с HTML5, CSS3 и прочими волшебными штуками.

Еще нынче модно использовать всякие Responsive Design, а кто-то даже считает, что без этого сайт вообще не современный, и не надо так. Но это тоже на вкус и цвет.

Если же вас вдруг интересует архитектура самой CMS (серверной ее части), то тут опять же все зависит от личных предпочтений. Что вам нужно, то и есть важные требования.

Тут как с выбором автомобиля. Кому-то спорткар: телок по клубам катать, а кому-то фургон: телок из загона к ветеринару катать.

Если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то у вас есть две проблемы.
Боян, но всегда в тему.

preg_match_all ( '/<a[^>]+?[^>]+>(.*?)<\/a>/i' , $txt , $matches); 
$info['TEST1:'] = str_replace("TEST1:","",$matches[1][0]);
$info['TEST2:'] = str_replace("TEST2:","",$matches[1][1]);
preg_match ( '/<span[^>]+?[^>]+>(.*?)<\/span>/i' , $txt , $matches);
$info['INFO:'] = str_replace("INFO:","",$matches[1]);
print_r($info);

Для разбиения даты все же используйте explode(). Не надо пихать регэкспы везде и всюду.

Вероятнее всего, движок самопальный.
Ничего сложного, насколько я вижу, в структуре нет. Но если нет желания связываться с разработкой еще одной CMS для банальной задачи, можно воспользоваться тем же WP.
Надо будет только тему подобрать. Или заказать. Если не ошибаюсь, подобные темы обычно находятся по запросам вроде «wordpress magazine template».

Открываете гугл. Выполняете пару запросов. Смотрите на изменения url, на основе чего делаете выводы о том, как url формируется.
Далее формируете список url для всех необходимых запросов, проходите по этим url, из отдаваемых данных с помощью регулярных выражений вытаскиваете число результатов (отображается под формой поиска).
Все это реализуется стандартными средствами PHP.
По необходимости можно усложнять и улучшать алгоритм до бесконечности.

«Руководство для начинающих» Шилдта не рекомендую. Слишком много воды. «Java 7» Хабибуллина понравилась больше, хотя суть примерно та же. Выбирая между двумя указанными, остановился бы на «Полном руководстве».