Внёс «небольшие» изменения на сайт
Вступление
И вот я сижу и думаю, а как вообще мой сайт работал без всего этого. Я провёл некоторые структурные изменения для сайта. В большей части, они коснулись именно внутренней перелинковки, в меньшей, содержимого сайта, хотя не без этого.
Про внутреннюю перелинковку
Я разделяю свой сайт на 3 уровня страниц:
- 1‑й уровень, он же верхний, содержит в себе домашнюю, страницу «обо мне» и контактную страницу.
- 2-й уровень это страницы пагинаций и фильтров, то есть статьи, инструменты и их вариации. Например, внутренние инструменты, или парсеры, или статьи про django.
- Наконец 3-й уровень это сами статьи.
Изначально, проблема была в том, что всё на 1-м и 2-м уровне страниц, подгружалось динамически, используя AJAX запросы. Взглянув со стороны производительности, скорости и доступности, можно сказать окей. Но проблема в том, что для гугла эти страницы были пустыми, а пагинацию он вообще не замечал, то есть для SEO это было просто ужасно.
Ну и конечно, я как главный герой, должен был это исправить или умереть пытаясь). Дальше, я опишу исправления для каждого уровня страниц.
Перелинковка домашней страницы
Начну с самого верхнего уровня сайта. Изначально, я планировал просто рендерить домашнюю на сервере (SSR), с возможностью дополнительных подгрузок контента на ней. То есть, вместо того чтобы делать AJAX запросы с самого начала, я бы их делал только после нажатия, кнопок ещё … или дальше. Но это решение требовало от меня сделать соответствующие элементы интерфейса для сайта, с соответствующими анимациями. И я такой, ну не и так пойдёт)
Так же для более гибкого управления ссылками и связями между страницами, я создал общую модель для сайта. Так её и назвал Website. Она невероятно проста и сейчас я могу менять работу пагинаторов(т.е. количество подгружаемых элементов), то какие категории отображать на главной странице или какие ссылки отображать в боковом меню или футере.
В будущем планирую улучшить её, с тем упором, чтобы менять стили и общий вид сайта. К примеру, создать рождественскую версию сайта)
Перелинковка страниц пагинации и фильтров с тегами
А сейчас о самом тяжком. Это было тяжело, даже для меня ʕ ·(エ)· ʔ . И я всё равно не смог сделать всё что хотел. Например, прогрузка элементов, которые были до стартовой страницы.(Начинаешь с 3-й страницы, 4,5,6 прогрузятся, но 2-я или 1-я уже нет). Или асинхронная, динамическая загрузка постов при нажатии на какой-либо из тегов.
Я следовал рекомендациям от Google, по созданию SEO-дружелюбного пагинатора + бесконечной ленты. И как пример, использовал этот сайт. Всё очень классно и понятно рассказано, но нехватает непосредственного кода на который можно было бы опереться или скопировать.
(Возможно сделаю статью про то как его сделать самому)
Но пагинатор это лишь первая половина пазла. Второй являлись теги. Вот тут я смог сделать и реализовать всё что хотел, включая разные теги для разных языков или возможность стакать эти теги (использовать несколько тегов за раз). При чём, самое интересное, всё это было сделано без скриптов. Всё реализованно на шаблонах от django(добавление, удаление и обновление тегов всё делают шаблоны)
(Возможно сделаю статью про то как реализовать свою собственную теговую систему)
Вообще, по идее, теги должны были быть с самого начала существования этого сайта. Но из-за того, что я имел некоторые skill-issue, я их не реализовал (^_^).
Перелинковка, непосредственно статей, контента на сайте
Суть перелинковки этого уровня сводиться к тому, чтобы отсылать читателей к релевантному и связанному контенту. Увеличение времени на сайте и глубины клика. Под кнопками «лайк» и «поделиться», могут появиться следующие блоки:
- Использованные внешние ссылки
- Использованные определения
- Связанные вопросы
- Похожие статьи
Ключевое слово здесь это могут. Все эти блоки опциональны и могут не появиться. Например, если внешние ссылки не упоминались, то и этот блок незачем.
Ещё хочу добавить то, что всё в этих блоках подтягивается автоматически, без моего участия. Хотя у меня есть возможность силой заставить показать нужное мне определение или вопрос.
(Возможно сделаю статью про то как сделать такое самому)
Удаление разделов новостей и кейсов
И теперь мы переходим к первопричине, того почему я вообще затеял создание пагинатора и теговой системы. Да, я просто хотел избавиться от этих категорий. Но не просто избавиться, а сделать так, чтобы они стали обычными тегами.
На данный момент, момент написания и публикации данной статьи. Все новости были перенесены в раздел статей с прибавлением к ним тега #Новость, а все кейсы были перенесены на раздел инструментов, но без специального тега. Это было просто не нужно.
Добавление галереи
Почему и зачем я её сделал? Я сам не знаю, ¯\_(ツ)_/¯. Может я просто увидел большие циферки в Google Search Console, тот раздел что про изображения, и решил, эта штука точно нужна. А может, я хотел создать свой “Masonry” ( это один из паттернов дизайна, где каждый элемент занимает ровно столько места, сколько необходимо чтобы не осталось промежутков между ними)
Кто знает, но я это сделал и уже ничего не изменить.
Выводы
Честно, рано ещё подводить вывод. Может через месяц-другой, но не раньше. Но вообще я надеюсь что ПФ(поведенческие факторы) улучшаться, в части глубины и времени. Плюс, как бонус получу баф к показам в поиске.
Но если, про недавние события и обновления я не могу пока судить, то вот судить свой сайт, которому скоро стукнет 1 годик, я вполне способен. Хотя буду делать это не здесь. Спойлер, спойлер скоро появиться ещё одна страница с открытыми данными о различной статистики про мой сайт. Грубо говоря Яндекс Метрика или Google Analytics, только встроенные в мой сайт.
Ну а пока, всем пока (づ ̄ ³ ̄)づ
0
Использованные термины
- Django шаблон ⟶ Это текстовый документ, который размечен специальным ситнаксисом для вставки кода в него.
- Django модель ⟶ Это менеджер баз данных во фреймворке Django. Реализованно в виде класов и наследования в Python
- Отрисовка на стороне сервера(ОСС) ⟶ Это метод, используемый в веб-разработке, который включает использование сценариев на веб-сервере, который создает ответ, настроенный для каждого запроса пользователя к веб-сайту. Сценарии могут быть написаны на любом из доступных серверных языков сценариев.
- Джанго фреймворк ⟶ Это высокоуровневый веб-фреймворк на языке программирования Python, который позволяет разработчикам создавать веб-приложения быстрее и с меньшими затратами на время благодаря своим мощным инструментам и встроенным функциям. Он был разработан для упрощения разработки сложных веб-сайтов и предоставляет множество «из коробки» функций
Релевантные вопросы
- Как работает проп children? Некоторые компоненты не знают своих потомков заранее. Это особенно характерно для таких компонентов, как Sidebar или Dialog, которые представляют из себя как бы «коробку», в которую можно что-то положить. Для таких компонентов мы рекомендуем использовать специальный проп children, который передаст дочерние элементы сразу на вывод
- Когда следует использовать встроенный стиль, а когда CSS? Используйте встроенные стили для динамических свойств стилей. Альтернатива CSS обеспечивает больше преимуществ, таких как автоматическое добавление префиксов, улучшенная отладка, медиа-запросы, ключевые кадры.
- Мое приложение некорректно отображается на сервере? Если это не работает, в 99% случаев это проблема конфигурации. Отсутствующее свойство, неправильный порядок вызовов или отсутствующий компонент — серверный рендеринг строго относится к конфигурации. Лучший способ выяснить, что не так, — сравнить свой проект с уже работающей настройкой. Ознакомьтесь с эталонными реализациями по частям.