Виктор Петров

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

Вообще говоря, народ в основном переехал на RankMath - всё то же самое, что AiOS и Yoast, только бесплатно и поболе в бесплатной версии.
Yoast с его бесконечными апдейтами и кучей мусора в коде я бы не порекомендовал. Ну жесть же: ставить плагин, который вырезает спамные комментарии Yoast из кода. А приходится.
Структура и архитектура WP сама по себе такова, что без тормозов, грязи в коде и тоннами запросов к БД иначе и не бывает. В принципе - это терпимо.
Если вы хотите уходить с AiOSP - ну, попробуйте Rank Math. Он даже настройки от старого плагина подхватывает, переход чаще всего абсолютно бесшовный и беспроблемный. Однако особого смысла в этом нет, там нет ничего принципиально отличающегося. Чуть пошустрее, чуть полегче, чуть подобрее. Не более.
И в целом: скорость загрузки - это, конечно, фактор, но слишком уж малый, чтобы ради его всерьёз перепиливать рабочий стафф.

Ну так под блок в адаптив css то есть? Там судя по всему дефолтные размеры трамбуются - и всё.

Всё, что не относится к формированию шаблона, и не представляет собой ценности как источник поискового трафика, нужно закрывать от индексирования. Есть поисковый спрос - отдайте в индекс. Нету - закрывайте от роботов.
Закрывать достаточно через robots.txt. В Yoast вы можете прописать мета robots с директивой noindex - но в данном случае это совсем не то, поскольку Яндекс не отличает пока сканирование от индексирования, для него это одно и то же, и при таком подходе вы будете постоянно сталкиваться с "колбасой" в индексе, кучей ошибок и скачками в ранжировании.

Тут два варианта: либо редиректит на уровне htaccess или functions, либо речь о плагине. Плагин можно отключить, а серверные редиректы найти в системных файлах.
Иначе, наверное, никак. В БД это едва ли есть.

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

Существует пачка генераторов соглашений такого рода - как в рунете, с учетом местного законодательства, так и в "бурже", с учётом законов ЕС и США. Оформлены в виде чеклистов, вам нужно лишь указать некоторые данные и отметить галочками интересующие поля.
Рекламировать конкретные сервисы не буду, в Яндексе находятся по запросу "генератор пользовательского соглашения для сайта".

Такой функционал решается плагинами на большинстве движков для интернет-магазинов. Классика - это Сотбит SEO умного фильтра для Битрикс.
Все эти плагины - платные, ценник - от 7 до 15 тысяч рублей. Функционал прост: при выборе фильтров идёт 301-й редирект со страницы фильтратора (неуникальной) на особую страницу, где выводятся отфильтрованные товары, но на уникальных метатегах, с уникальным заголовком h1, своими текстовыми блоками.
Насколько я помню, для WooCommerce был такой плагинчик, но довольно кривой.
Рекламщикам стоило бы закатать губу: задачка довольно сложная, и разработка кастомного модуля может оказаться подороже всего сайта. Хотя, собственно, вот сейчас без такого модуля сайт магазина уже никуда не поедет.
Для примера реализации на кастоме (там не WP) можно посмотреть каталог bestceramic.ru: там фактически любое сочетание фильтров отдаст не страницу фильтрации, а полноценную посадочную страницу. Однако надо понимать, что чаще всего речь идёт не об автогенерации на шаблонах. Нужно внести условия под заданные фильтры, автогенерация будет только во вред.

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

Думаю, сама по себе формулировка запроса не очень корректная. В рамках Wordpress структура всё равно будет стандартной для WP с базой в таксономиях. В вашем случае едва ли есть смысл углубленно прорабатывать семантику с опорой на поисковый спрос. Однако и обычными листингами обойтись не удастся., поскольку в рамках Wordpress всё построено на обычных "лентах" по категориям и тегам.
Я бы предложил проработку страниц-хабов, то есть страниц портального типа – примерно так, как сделано в интернет-магазинах. Частично она должна основываться на поисковом спросе: самые востребованные категории стоит вывести в отдельный блок в любом случае. Остальное – на подборках по популярности, рейтингам (тут уже думать - каким), языкам.
Обязательно добавить фильтратор и поиск.
В целом - стоит оценить топовые сайты в этой тематике и посмотреть соответствующие шаблоны WP для интернет-магазинов. Как правило, там хорошо реализовано и тегирование, и фильтрация, и прочие инструменты структурирования контента.
Отдельная тема - настройки пагинации. В вашем случае едва ли стоит закрывать страницы пагинации от сканирования роботами, правильнее присвоить канонический URL, а сами канонические "посадки" не оставлять в виде обычных листингов.

Я бы сказал, что это пустая трата времени. Циклическая ссылка на логотипе с главной ни на что не влияет. Это не ошибка.

Наличие таких ошибок - явный признак ошибок на уровне htaccess (кольцевые редиректы) и присутствие ссылок на этот мусор в рамках сайта. парсер их каким-то образом находит, и робот отправляется по кольцу. Ошибка может быть буквально фатальной в Google, таким образом целые разделы могут оказываться вне индекса, гуглобот до конечной страницы просто не доходит.
Частая причина, помимо ошибок в htaccess - удаление товара с 301-м на главную страницу или категорию, без удаления ссылок на удаленное с сайта, или битые canonical, и целые связки таких ошибок.
Я бы посоветовал спарсить сайт любым доступным парсером (Screaming Frog Seo Spider, SiteAnalyzer и т.п.) и посмотреть на редиректные URL, присутствие их во входящих внутренних ссылках) и после этого ставить конкретные диагнозы и вносить правки.