shinkareff
Ответы в темах
-
Форум: Проблемы и решения
Тема: Дублирование страницКаноникалы не решают всех проблем с дублированием, уверяю Вас. Они всего лишь указывают на основную страницу, среди дублей. Причём, поисковые алгоритмы ещё умудряются иногда их игнорировать.
- Ответ изменён 4 года, 10 месяцев назад пользователем shinkareff.
Форум: Проблемы и решения
Тема: Дублирование страниц@flector, каноникалы — третий по важности этап. Мне сейчас надо избавиться сначала от дублирования, далее — от четыреста четвёртых, которых стало слишком много. Сайт несколько раз мигрировал на новые платформы и я им не занимался. 90% от всех урлов содержат ошибки.
Форум: Проблемы и решения
Тема: Дублирование страницЕсли кому-то поможет: справился со всеми проблемами с помощью нескольких плагинов и директив в htaccess. Только в первом случае, метки UTM победил не совсем корректно. Теперь нельзя перейти в результатах поиска дальше первой страницы. Но, пока оставил так. Всем спасибо, тему можно закрывать.
@alexander70 Использовал. Три месяца назад отключил на всех сайтах.
Как и предполагалось изначально, виноваты плагины. Точнее, один из них.
@eugsan, действительно, проблема в NextGEN. Отключил его неделю назад. За неделю база выросла на 400 килобайт.
Грешил на него в последнюю очередь, потому что на другом сайте тоже он работает. Галерей примерно одинаково и посетителей тоже. На том сайте ничего подобного не происходит.
Видимо, влияют настройки сервера или ещё какая-то магия. В общем, загадка разрешена. NextGEN давно своё отжил, но всё никак руки не доходили перенести галереи в медиабиблиотеку ВП.
Коллеги, благодарю за консультации!
В общем, ничего не помогает. За прошедшие 7 суток — лишних 12 мегабайт.
@yube Юрий, а если оптимизация БД затрагивает только пустое место — почему его так много? 12 мегабайт «дырок»?
Итак, коротко о том, что выяснил: до и после оптимизации количество строк в таблице не уменьшается. Больше всего строк типа:
— transient_amp_img_***
— transient_timeout_*__***
— displayed_gallery_rendering_***@yube, колонки «Overhead» в таблице нет. Только id, name, value и autoload.
Попробую по очереди отключать плагины. И фиксировать изменения. Долгий процесс. Но, другого способа не могу придумать.
В основном меню phpMyAdmin можно увидеть какая таблица весит больше
@otshelnik-fm, речь только об одной таблице «options». Растёт она.
Но это не покажет если у вас 10000 мелких строк в опциях.
Вот в этом и проблема.
Еще могу предположить что плагин безопасности настроен на разных сайтах по разному
Нет, защиту на этот сайт поставил две недели назад, когда у турков сезонное обострение началось. Этот плаг не при делах. Проблема возникла полгода назад.
Завтра попробую сортировкой по ID отфильтровать. Напишу о результате.
К сожалению, так и не смог сделать снимок базы. До оптимизации показывает размер таблицы «options» — 7 мегабайт. Выгружаю дамп этой таблицы без сжатия, скачивается 1 мегабайт. Провожу оптимизацию, в PHPMyAdmin размер таблицы уменьшается до 0,9 мегабайт. И скачивается дамп такого же размера. Мистика какая-то.
Единственная гипотеза: перед выгрузкой дампа PHPMyAdmin сам делает оптимизацию.
@m0ze, не знаю, о чём говорит Вам моя фраза. Надеюсь, Вы не ставите целью меня задеть. А действительно хотите помочь.
Чем и как проверять сайты и защищать их — выбор каждого пользователя. Если за 20 лет мои сайты сломали лишь один раз и то, потому что я сам забыл закрыть директорию на запись — вероятно, выбор инструментов защиты не самый плохой.
Код я попробую показать, сегодня или завтра. Сделаю снимки таблицы до и после.
@fierevere, дело в том, что я не кодер. Ну то есть совсем. Чтобы разобраться, сравнивал содержимое таблицы «options» до и после оптимизации. Удаляется очень много просроченных транзиентов и какие-то данные, которые я не могу расшифровать. В поиск их вбивать бесполезно, Гугл этого запроса не понимает.
@fierevere, ревизии отключены. Один раз в неделю удаляю транзиенты, чищу прочий мусор и провожу оптимизацию базы, на всех своих сайтах. Таблица «options» растёт только на одном. Не особенно парит, можно поставить оптимизацию на автомат. Но, тут уже чисто спортивный интерес: почему именно на этом сайте и как отловить баг?
Откуда такая уверенность?
@m0ze, один раз в неделю проверка внешним сервисом и один раз в неделю проверка с помощью Wordfence Security. Уверенность из собственного опыта, я занимаюсь сайтами 20 лет, и с WordPress работаю с первой публичной версии.
Обычно базу грузят всякие логи, статистики и метрики, плагины безопасности и анти-спама. У _options ещё есть временные опции
Если бы задача решалась так просто, я бы её уже решил. На одном хостинге, на одной площадке, на одной БД работают 9 сайтов на этом ПО. С одинаковым набором плагинов. Проблема только с одним сайтом, причём он не самый большой по количеству страниц.
Ну и для полноты картины: на двух других хостингах работают ещё примерно два десятка сайтов, тоже на ВП, настройки и плагины примерно одинаковы. Тоже не наблюдаю ничего подобного.
Ещё бы хорошо понять, сколько это ожидание может длиться: неделю, месяц, год? Написал в их Твиттер-аккаунт, на всякий случай. Странно то, что на полусотне сайтов проверил — на всех запрет работает, кроме одного.
Благодарю. Буду ждать.