Головна → Різне → WordPress SEO, базова оптимізація
Багатьом з нас, як розробникам, так і маркетологам, власникам сайтів, не кажучи вже про оптимізатор, доводиться так чи інакше стикатися з SEO.
Відразу зазначу, що WordPress в цьому плані система дуже гнучка і доброзичлива, але так само, як і будь-яка інша, потребує деякої доведенні в ручному режимі, щоб досягти максимальної ефективності. Саме про це і піде мова.
З цієї статті ви не дізнаєтеся про методи нарощування посилальної маси, про правильну оптимізації тексту сторінок, а так само про багатьох інших складових SEO. Про що ж тут буде йти мова? Про основи, про базову оптимізації, підготовці WordPress для подальшої, так би мовити «тонкої», настройки.
Відповідаючи відразу на питання «А що це таке взагалі - базова оптимізація?»: Базова оптимізація - це така корисна штука, яка дозволить вам заощадити купу часу, ресурсів і сил в подальшому в незалежності від обраної вами стратегії оптимізації та просування.
Базова оптимізація - це правильні настройки варіантів, пропонованих системою, це плагіни, що автоматизують більшу частину роботи, це підкладання соломки заздалегідь там, куди теоретично може приземлитися ваш зад.
Не мудруючи лукаво перейдемо до суті.
Пермалінкі або ЧПУ
Налаштування постійних посилань
Можете сміливо брати на озброєння, або використовувати список доступних тегів і створити своє власне висловлювання.
Плюс кириличні символи при перекодуванні дають більшу кількість символів в URL, ніж латиниця. Полегшувати чи пошукачам і тим, хто не використовує UTF-кодування, завдання чи ні - вирішувати вам, але я б рекомендував скористатися, наприклад, плагіном Cyr to Lat Enhanced і перевести-таки кирилицю в латиницю автоматично, або писати посилання на англійському вручну.
«Твоя моя розуміти?»
Якщо публікуєте дійсно важливу статтю і використовуєте транслітерацію в URL - не полінуйтеся і перевірте, чи правильно вас розуміють основні пошуковики.
Перевірка транслітерації в Google
Перевірка транслітерації в Яндексі
Причому позитивний результат в одному не є гарантією позитивного результату в іншому. На жаль ГОСТ тут не працює і пошукові системи використовують власне розуміння транслітерації.
Визначтеся з основним дзеркалом
Проблема стара як самі пошуковики, проте вона досі вимагає уваги, так як вони все так же іноді помиляються, а втрачати через це вага не дуже-то хочеться. Визначаємо для WordPress (Установки → Загальні) який саме варіант подання нам потрібен - з www або без.
канонічні посилання
Для того, щоб підказати пошуковій системі правильне посилання і не втратити при склеюванні безповоротно контрольний вагу, проставляємо канонічні посилання на кожній сторінці у вигляді такої ось записи в розділі
:Полегшити життя в даному плані і проставити все вірно і автоматом можуть такі плагіни, як, наприклад: WordPress SEO by Yoast або All in One SEO Pack.
Таксономії в розрізі WordPress SEO
WordPress за замовчуванням пропонує вам таксономії з вертикальної (рубрики) і горизонтальної (теги / мітки) ієрархією. Чи не гребують використовувати їх на всю котушку.
WordPress підказує часто використовувані на вашому сайті мітки - користуйтеся його допомогою. Ну і, звичайно, не спамьте непотрібними мітками там, де вони не до місця.
Логічне поділ по вертикальній ієрархії дасть деякий плюс як в просуванні основних тематичних запитів сайту, так і полегшить завдання пошуковим системам в тих випадках, коли вони захочуть виділити на сайті основні розділи і показати з рядом зі сніпетів у видачі.
дублювання контенту
На цю тему, як завжди, ведеться безліч суперечок, але всі погоджуються в тому, що дублів контенту краще на сайті уникати.
Ну і головний мінус: навіть якщо ви не потрапите під жодні санкції від пошукових систем за дублювання контенту (зокрема Google обіцяє не карати. Якщо немає злочинного наміру), то в пошукову видачу потрапить все одно тільки один з дублів і не факт, що потрібний вам.
Ще один крок на шляху базової оптимізації, який ви можете зробити - не виводити в стрічки (loop) записи цілком. Використовуйте функцію the_excerpt () замість the_content ().
Таким чином ви, по-перше, полегшите завдання пошуку користувачеві, який може потрапити на сторінку в пошуках певної фрази з пошуковика. Краще б йому не мотати солідне полотно, а відразу побачити шукане на сторінці. По-друге, не виводячи все вміст поста в стрічку ви зменшите кількість дубльованого контенту на сайті.
Посилити останній ефект ви можете шляхом написання в Цитату (Excerpt) короткого змісту поста, замість його першого параграфа (як було б, використовуй ви the_content () з відрізує рядком в контенті).
Robots.txt
В налаштуваннях за замовчуванням WordPress пропонує тільки включити або виключити індексацію сайту повністю. Якщо ж ви хочете більш тонких налаштувань - все просто:
- створіть фізичний файл в корені сайту. Ніяких конфліктів не виникне. Якщо фізичний файл існує, пріоритет автоматично віддається йому;
- або скористайтеся плагіном, який дозволить вносити розширені зміни в віртуальний файл.
Sitemap.xml
Без сумнівів потрібний файл для прискорення індексації пошуковими системами. За замовчуванням в WordPress відсутня, тому що занадто багато варіантів того, що саме ви захочете включити в цей файл, а тому наявні варіанти:
- скористатися плагіном (наприклад: Google XML Sitemaps. WordPress SEO by Yoast. All in One SEO Pack), налаштувати і генерувати автоматично;
- скористатися будь-яким онлайн сервісом (просто вбийте в пошуковику XML Sitemap), генерувати за запитом і розміщувати у себе;
- написати висновок самому.
Зі звичайної трійці (Title, Description, Keywords) WordPress за замовчуванням для постів і сторінок підтримує тільки Title (функція wp_title ()), який відтворює назву посади / сторінки. Для всього іншого вам знадобляться спеціалізовані плагіни, або використання довільних полів.
Допомогти в даному випадку можуть Такий модуль
І наостанок - Favicon, та сама, давно всім знайома іконка. За замовчуванням в ядрі WordPress не підтримується, тому розміщуємо в корінь сайту самі і додаємо посилання в розділ
, або використовуємо плагін, наприклад: Heroic Favicon Generator.Нагадаємо, що мова у нас йде тільки про базову оптимізації, а не про те, як заточити сторінку під ключовий запит, а тому лише конкретні рекомендації, придатні до загальних випадків.
Оптимізуйте теги зображень - пропишіть всі атрибути (alt, title). WordPress за замовчуванням дає таку можливість. Не лінуйтеся і ключові слова в атрибутах зображень приємно здивують вас підвищенням тематичного ваги ваших сторінок. Головне - без спаму як попало.
Атрибути зображень в WordPress
Розкажи всім (ping)
За замовчуванням в WordPress прописаний тільки один сервіс - Ping-O-Matic. Для багатьох цього достатньо, але для естетів я б рекомендував додати пару сервісів додатково:
На закінчення
На цьому наші кроки на шляху базової пошукової оптимізації WordPress закінчуються і хочеться вірити, що більшість з порад описаних в статті, будуть застосовані вами і заощадять надалі ваші час, сили і гроші.
Незаперечно :) Просто я вважав, що мікророзмітки (Opengraph, Schema.org Microdata, Twitter Cards, Dublin Core ...) - річ специфічна, а не базова. Тому я обмежився зазначенням в розділі «HEAD-поля» плагінів (зокрема - Add Meta Tags), які полегшують її використання при необхідності.
Я все поні звичайно але навіщо favicon радити корінь класти, давайте
css теж в корінь сайту винесемо. якщо вже в head додавати то невже до каталогу шаблону сил не вистачить шлях прописати
О, тут все просто :)
Основна причина - багато браузери жадають побачити іконку саме в корені сайту і роблять відповідний запит ще до того, як запросять і пропарсят код сторінки на предмет явного вказівки посилання на якусь вкладену папку. І якщо вас не бентежить зайвий 404 відгук для вашого сайту (шкода і правда не великий, але ...), то бруднити логи PHP цією помилкою, особливо на проектах з високою відвідуваністю - не дуже добре. Хоча в nginx, наприклад, і можна прописати редирект, але чи потрібно?
Плюс до того - в корені добре розміщувати на випадок частою (хоча це поняття відносне) зміни тем / правок шаблонів сайту. Але це вже можна назвати специфікою роботи, тобто особистим перевагою.
Навіщо в такому випадку додавати тег в код сайту, а не обмежитися просто запиханням в корінь? Банальна валідність коду плюс можливе прискорення індексації у разі зміни іконки.
Якщо комусь раптом знадобиться для nginx;)
проблеми дві якщо закинути в корінь іконку то:
не факт що вона в бекап потрапить, так як часто з кореня бекап wp-config.php і все.
іконка не змінюватиметься вшити з шаблоном. це теж не дуже добре.
Коли сайт переносиш куди або іконка втрачається зазвичай, і цього не помічаєш навіть.
Вихід як вище показали можна засобами веб сервера позбудеться цієї зайвої 404 помилки можна хоча б wp-content кудись іконку полохжіть там вона забекапітся хоча б.
та й логи бруднити теж не проблема
location = /favicon.ico log_not_found off;
access_log off;
>
C wordpress.org начебто шматочок конфіга.
Ну, тут навіть сперечатися особливо немає з чим) Інакше обговорення ризикує перетворитися в холівар :) Швидше висловлю свою думку.
Як черговий окремий випадок, наприклад, при роботі через GIT абсолютно без різниці - що саме з файлової структури бекапіть.
На тему того, що ікона може загубитися при перенесенні і цього не помітиш - ну ... Можна взагалі багато чого не помітити, якщо на те пішло ... Все переносять по-різному, з різним ступенем уваги, різними засобами. Наприклад на новому серваке вам в будь-якому випадку тоді доведеться знову ж таки не забути прописати редіректи для іконки і т.д.
Якщо іконка не змінюватиметься разом з шаблоном - по мені так це чудово, якщо логотип у компанії / фірми / людини один і змінюються виключно шаблони (найкраща оптимізація, юзабіліті, нові фішки в дизайні і т.д.) і все, чим ти ризикуєш щодо favicon - це просто не прописати тег для валідності, але в пошукових системах помітність не погіршиться.
І так - можна виключати непотрібне з логів, можна ставити редіректи, застосовувати різні системи версійності даних, коротше кажучи - допілівать під себе скільки душі завгодно :)
Ну може в цьому сенс і є, але як на мене країни спосіб
Тому вибирайте ту структуру, яка матиме більший сенс для вашого проекту. Якби був один єдиний правильний формат, то розробники WordPress не пропонували б користувачам вибору.
Може бути і підкажу;)
Андрій, щоб не боліла голова, можу порадити такий плагін, як Redirection. Він дозволяє створювати редіректи без влізання в .htaccess і взагалі на сервер. Можливо вам підійде такий варіант. Просто пропишіть 301 редирект з site.ru/plagin/ на site.ru/wordpress/plagin заодно переконайтеся по лічильнику в цьому плагіні, що мало який птах долітає до таких посилань) Зазвичай вони ніде не світяться за замовчуванням.