Портал Belkin-labs»PHP классы»Статья
welcome!

Управление meta-тегами страниц сайта: мои хотелки и океан возможностей

Не буду расплываться мыслью и расписывать, что имеется ввиду под meta-тегами страниц сайта, и как они важны для SEO, а значит и для каждого владельца сайта. Эти самые мета теги с подачи поисковиков приобрели просто сакральное значение. Я тоже поначалу верил, что манипуляцией этими самыми тегами можно волшебно поднять сайт на первые страницы поисковых сервисов. Как бы там ни было, поисковики действительно уделяют этим тегам довольно большое значение, о чем и пишут в своих руководствах.

Что подразумеваем под мета-тегами чисто для определенности терминов

Здесь я озвучиваю свой личный подход к предмету исследования. Он может несколько отличаться от официального.

  1. В первую очередь тег title.
  2. Во вторую очередь теги типа <meta name="..." content="..." />
  3. В третью очередь тег типа <link rel="canonical" href="..."/>. Строго говоря, это вообще не мета-тег.

Вот и весь список. Он может быть большим, ибо количество тегов в пункте 2 не определено заранее и может быть бесконечным. Как минимум это теги с именами (атрибут name) description, keywords, robots.

Итого в список мета-тегов каждой страницы входят как минимум 4 обязательных и 1 необязательный.

Тег типа <meta http-equiv="Content-Type" content="text/html; charset=windows-1251" /> я не включаю в состав мета-тегов. В моих терминах этот тег является общим атрибутом всех страниц сайта наравне с Doctype. Очевидно, раз этот тег логически принадлежит сайту, то и рассматривается он в категориях всего сайта сразу, а не в разделе каждой его страницы. Конкретно он принадлежит классу заголовка страницы и будет рассмотрен значительно позже.

Где хранить мета-теги?

ООП приложения нужно хорошо и тщательно разрабатывать перед тем, как приступать к программированию. В этом их основная сложность. Роль разработки куда больше роли собственно программирования. Практика же складывается так, что программировать люди любят больше, чем разрабатывать. Разрабатывать многим скучно, особенно молодым! Отсюда, кстати, проистекает обилие ненадежного, рискованного, откровенно мусорного кода. В свою очередь хорошая разработка уменьшает количество труда по программированию, что тоже многих от процесса разработки отталкивает. Я сам такой был. Теперь полюбил разрабатывать. Видимо возраст дает себя знать.

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

Если мета-теги - это часть документа, то что тогда делать с многостраничной категорией каталога продуктов? Грубо говоря, с разделом "телефоны Nokia"? Мета-теги у каждой такой страницы очевидно должны быть, причем уникальные, а документа вроде как и нет! Ну, предположим, под документ можно натянуть некое описание категории. Но что тогда делать со страницей № 2,3 и тд этой категории?

Другой вопрос. Если у вас страница формы контактов выполнена на отдельной странице, и эта страница не имеет сответствующей записи в базе данных, то где прописывать ее мета-теги? Прямо в коде страницы? В скрипте? Ну, предположим, прямо в скрипте. Но тогда получается, что мета-теги статьи надо запоминать в статье, мета-теги генерируемой страницы прямо в скрипте страницы, а мета-теги страницы каталога можно запоминать и в документе "Описание категории", но подправлять их в скрипте, чтобы как-то вставить указание на то, что это документ многостраничный. В качестве яркого примера можно взять и каталог новостей. Там даже описания нет, а страниц может быть бесконечное количество.

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

Где я храню мета-теги?

Ну я в какой-то момент (это было много лет назад) этим вопросом задался. Более того, я был молодой и горячий и я многие вещи вот так сразу запрограммировал. Эти пробные подходы высветили проблемы. Проблемы хранения и, соответственно, проблемы поддержки, то есть, редактирования. В итоге, после некоторых творческих мучений я, можно сказать, прозрел и решил, что если есть затруднения с определением логической принадлежности мета-тегов, то надо выделить их в отдельную логическую сущность. Поскольку на самом общем уровне страница нашего сайта состоит из заголовка и тела (теги head и body), то мета-теги есть отдельный логический объект и он является частью заголовка. Напомню, что в заголовке мной уже затронуты две похожие друг на друга подсистемы - это линки на файлы стилей (вместе с тегом style) и ссылки на файлы скриптов JS и сами скрипты, то есть, теги script.

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

Но это все не значит, что мета-теги, да, кстати, и сам URI не связан с документом, статьей, продуктом или категорией каталога. Связаны и очень сильно. И вполне можно сделать редактирование мета-тегов на той-же странице, где происходит и редактирование документа. Но я так не делаю. Мне удобнее зайти на страницу и в режиме администратора прямо на ней нажать на ссылочку и отредактировать все ее мета-теги. Мне удобно именно так. Но, что странно, я пытаюсь продвинуть этот подход в среде моих клиентов и он не встречает понимания. Удивительно, но факт. Абсолютное большинство клиентов ассоциирует мета-теги страницы только с документом и ни с чем иным, и отдельная форма редактирования мета-тегов и URI их абсолютно не устраивает. Только редактирование всего документа в одной форме и никак иначе.

Сервис управления мета-тегами

Мы уже решили относиться к мета-тегам как к отдельной сущности и части заголовка страницы. Что является сервисом этой сложной сущности?

Три набора мета-тегов и их приоритет

Я хочу иметь 3 набора мета-тегов.

  1. Набор, который должен храниться в базе данных в таблице мета-тегов. Он может не существовать. Просто потому, что нет записи в таблице.
  2. Набор, который находится в массиве и который я передаю (а может быть и не передаю) в класс шаблона. Такой набор тоже может существовать, а может и не существовать
  3. Набор, который находится в конфигурационных константах и который существует всегда и который используется в том случае, если первых двух нет, либо в результате их использования получается неполный набор.

Причем я как всегда хочу иметь по возможности полный контроль и мне нужно, чтобы указанные наборы заполнялись последовательно. Сначала в качестве источника используется один, потом элементы, которые оказались пустыми заполняются из другого, а потом и из третьего. Поскольку третий набор всегда существует и всегда полный, то и страница у меня всегда имеет полный набор мета-тегов. Но тут возникает вопрос приоритета. Какой набор имеет приоритет и заполняется первым? Первый или второй? У меня так сложилось, что мне нужны оба приоритета. Таким образом, мне пришлось и запрограммировать оба приоритета, то есть приоритет базы и приоритет массива.

Домены

В моей практике в некоторый момент произошел довольно серьезный этап. На этом этапе я перешел от папок одного домена к сайту, объединяющему несколько доменов третьего уровня. В связи с этим мне пришлось в таблице мета-тегов добавить в первичный ключ поле, определяющее домен. Но у основного домена обозначение домена третьего уровня есть пустая строка. Пустая строка может быть ключом массива в PHP и ее можно сделать константой. Но мне показалось это несколько экстремальным с точки зрения программиста и я ввел специальное обозначение домена третьего уровня для основного сайта. Это нововведение довольно сильно усложнило всю ООП конструкцию и пока это обозначение работает, но я уже думаю перейти обратно к пустой строке.

Предупреждения администратору

У меня в практике были случаи, когда после ночных и спешных преобразований у меня система мета-тегов давала сбой и все страницы сайта подряд получали мета-теги третьего уровня, то есть те, что в константах записаны. Замечал я это обычно слишком поздно, когда обрушивалась посещаемость сайта. После этого я от греха подальше предусмотрел возможность отсылки письма администратору сайта в случае, если в текущей открываемой странице не полный набор мета-тегов и какие-то отдельные мета-теги заполняются из констант.

Генерация мета-тегов

Опять же в моей практике были случаи, когда мне захотелось попробовать генерировать мета-теги для того, чтобы они были разные и никогда не повторялись для большого количества однотипных страниц. Для этого я использовал небольшой класс, который составляет текст из альтернатив. Есть даже синтаксис специальный для этого. Но мы не должны каждый раз при входе на страницу генерировать ей новое описание. Мы должны сгенерировать его один раз и запомнить, а при повторном входе уже взять из базы данных и больше не генерировать. При реализации этого сервиса выяснилось наличие большого количества подводных камней и других нюансов. Например, при генерации мета-тегов мне бы не хотелось получать письмо. Просто таких писем может быть очень много, а в случае большого числа параметров, на основе которых генерируется контент, их может быть даже слишком много! Например, страницы, которые показывают материалы (статьи) удовлетворяющие одному или нескольким ключевым словам. В зависимости от сочетания ключевых слов может быть непредсказуемое количество страниц.

Последнее изменение мета-тегов

Схема заполнения мета-тегов из 3-х источников удобна и в 99% случаев устраивает. Но есть у меня еще один сервис, который я даже не знаю, как появился. То есть, он есть, но когда я его использовал, и зачем создавал, и кто заказывал, если вообще заказывал, я не помню. Сервис условно можно назвать "последнее изменение". То есть, например, все страницы как страницы, но есть среди них такие, на которых надо поставить ROBOTS = "noindex, nofollow". Так вот есть сервис, который позволяет сделать последнее изменение мета-тегов перед самой вставкой на страницу. Реализован этот сервис в виде метода - события, который выполняется в самом конце, при формировании html-кода мета-тегов.

Эпилог

Эпилог как всегда оптимистический и жизнеутверждающий. Как видите, система учета мета-тегов значительно проще и для разработки и для реализации, чем те же CSS стили. Структура наследования классов следующая:

  • базовый класс;
  • базовый класс с усложнением для портала со многими доменами третьего уровня;
  • класс уровня проекта;
  • класс уровня сайта обычно не бывает нужен.

Автор php-тулбокса для программирования сайта
Дмитрий Белкин

Статья создана 15.01.2015
Похожие материалы - отбираем по ключевым словам