Я эволюционно шел:
- Сначала просто вбивал переменные в методе формирования контекста.
- Добавил стандартные мета-теги в модель с настройками (на случай, если нечего вбивать).
- Добавил мета-теги в модель, допустим, с категорией и понял, что стоит создать абстрактный класс, от которого позже наследовал и базовые настройки и эту модель.
- Понял, что вьюхи сильно дублируют код: постоянно присваиваю переменным одно и то же.
- В базовой вьюхе определил переменную, которая определяет, какие мета-теги используются, для каждой из них сделал метод ее получения, теперь во вьюхах пишу просто список мета-тегов, оно пытается выгрузить их из модели, либо найти метод, который их вернет (такой метод нужен на случай, если мета-теги не заполнены и нужно вместо seo_title подставить просто name).
- Понял, что, по-хорошему, тут нужно создать приложение, которое сможет расширять любую вьюху. То есть отвязать его от моей базовой вьюхи и подарить сообществу.
- Наконец-то решил погуглить: нашел django-meta, которое делает все то же самое, только чуть более изящно, автор явно прошел дальше по эволюционной ветке.
- Приуныл, собираюсь использовать вот буквально завтра.
Оно выглядит хорошо: предоставляет базовый класс с мета-тегами, миксин для вьюхи (который экземпляр класса добавит в context). Можно забить мета-тег либо статично во вьюху, либо сделать метод для его динамического получения. Вкупе с абстрактной моделью это получается удобно, в данный момент я не могу придумать лучше.
Да, что касается админки. Если там нужны какие-то стандартные действия с полями SEO, типа как добавление их в fieldsets, лучше тоже создать миксин, который переопределил get_fieldsets, например (или что там у вас).
p.s. Я не думаю, что все это имеет смысл на сайте-визитке, например. Я бы делал такое начиная с масштаба интернет-магазина и более.
