Анна

Как понять, где лучше использовать плагин, а где лучше разобраться и вставить код?

Вопрос в корне не корректный. Плагин - это тоже код. Вопрос его качества.
А разобраться где какой код использовать (в теме или плагине) не сложно: то, что не должно пропасть при смене темы должно быть реализовано в плагине.

На данный момент использую:

Всё фтопку! (разве что мегаменю можно оставить если это реально нужно).
А картинки нужно готовить заранее.

Какие плагины обязательны?

Не бывает таких. Зависит от задач сайта, квалификации разработчика и некоторых других условий.

Как сделать сайт на WordPress с высокой производительностью?

Для этого нужно много знаний и опыта.
Начиная с понимания, что простого однозначного универсального ответа на этот вопрос быть не может в принципе.

Ну или обратиться к специалисту, (если нужен именно сайт, а не самостоятельно покнопать)

В базе данных в таблице wp_posts

Дизайн хранится в файлах темы header.php, footer.php, page.php...

Первый же результат из Гугла на тему структуры хранения wordpress https://wp-staging.com/docs/the-wordpress-database...

Нынешняя работа с индексированием – это сплошная борьба с техническими дублями, которые плодят сами ПС.
В данном случае рекомендую для Яндекс использовать Clean-param, чтобы подклеить эти дубли к целевой странице. Закрывать в robots.txt не стоит, поскольку потеряете все полезные сигналы, в том числе и с выдачи. если они там есть. А это может быть весомо.
Для Google можно не морочиться, он справляется с параметрами лучше, чем Яндекс, и в принципе в индекс что-то берет крайне неохотно.

С некоторого времени в Вебмастере стали появляться ссылки, например /?_ym_debug=2 или /?gtm_debug=1729657003761.

Подскажите, пожалуйста, где мне найти источник проблемы?

Проверка цели. У Вас не запрещена индексация страниц с не нужными url параметрами. По идее, поисковик воспринимает такие страницы, как дубли.

Пример запрета индексации любых url с url параметрами без слэша на конце (robots.txt):

User-agent: *
Disallow: *?

Со слэшем:

User-agent: *
Disallow: */?

Правило размещать в начале файла, затем, его ниже можно перекрыть, написав новое Allow правило, это необходимо для разрешения индексации страниц с определенными url параметрами.

1) Получать с сервера ссылку, а не подставляя ее в js.
2) Записывать куда то определенный hash на открытие страницы
https://мойсайт.ru/страница-благодарности.php?hash=123 и потом гасить его, чтобы человек не мог повторно открыть страницу.

Возможно просто рендер страницы благодарности вместо формы отрисовать после события успешной отправки формы.

Яндекс больше не позволяет парсить запросы из Вордстат. Для этого можно использовать API XMLRiver. Платный, разумеется.
Запросы можно взять из Букварикс, он сейчас абсолютно бесплатен.
Частотность парсится через Директ - там ничего не надо, просто яндексовые учётки с привязанным телефоном (одним на всех). Кабинет не нужен.
Выдача парсится тоже по XML - либо с помощью xmlriver, либо с помощью xmlstock.
Нюанс. Для парсинга из Директа всё же нужно брать Rucaptcha. Это очень дёшево, но без неё никак. Мне в среднем рублей 200 хватает на пару лет, при том, что парсить приходится много и регулярно.

OpenServer запрещает задавать имена доменов с нижним подчеркиванием. Замените недопустимый символ на тире "sibarit-su". Должно заработать.

Сайт самописный, на HTML, CSS, немного JS и обработчик формы на нативном PHP.

Как следствие этих попыток, остались файлы WP в корневой папке. Похоже, это ни на что не влияет, но если я ошибаюсь - поправьте меня, возможно, это не так.

Если это обычная статика, то скорее всего у Вас нет правил роутинга, соответственно так же будут попытки индексации этих (wp) директорий и файлов внутри них, что не очень хорошо.

Добавляла новые страницы, обновляла контент на уже существующих, расширяла семантическое ядро новыми запросами, добавляла микроразметку.

Очень хорошо, поисковики любят постоянное добавление и минимальное обновление контента.

Я использовала только белые методы продвижения, не закупала ссылки пачками, не накручивала пф.

Вы точно уверены, что правильно закупали ссылки и создали правильный ссылочный профиль? Да и ссылки для Яши играют далеко не определяющее значение, не то что для гугла.

Несколько дней назад добавила в .htaccess код для того, чтобы убрать из поиска index.html:

Это одна из базовых вещей внутренней оптимизации (robots.txt туда же), которую необходимо выполнить одной из первых. Вы уверены, что у Вас Apache, а не Nginx? Так же RewriteEngine On достаточно включать 1 раз в блоке, 2 не обязательно.

То есть фильтров нет.

Не всегда напрямую об этом говорят.

Я совсем не понимаю, что происходит и как вернуться на прежнее место на 1 странице выдачи по ключевым запросам средней частотности.

Очень мало данных Вы предоставили, чтобы можно было за что то зацепиться. Трафик упал (вместе с позициями) только в Яше, или в Гугле так же? Какие действия Вы производили за месяц до этого?

Вижу, что прошло всего ~3 суток, а Вы уже бьете тревогу, это конечно хорошо, но иногда поисковики штормит и это Вам не изменить.

Яндекс обновляет алгоритмы определения качественно...
Новый алгоритм Яндекса 2024 под названием «Косяк»

<meta name="description" content=""<?= $description ?>>

Вы видите, что у вас текст description вставлен мимо кавычек, после их закрытия?

Как написали выше, все возможно. Вам если не обращаться к CMS, то просто забить все в базу данных и оттуда тянуть.

Могу подсказать куда копать, или фрилансера)
t.me/lovtin напишите в телеграмме

- "Я правильно понимаю, чтобы выложить файлы в формате php, нужно создать какую-то базу данных?"

Нет, для работы php не требуется база данных, если это не определено в коде php

Просто копируйте все файлы из локального каталога, в рабочий каталог на сервере, если файл конфигурации настроен правильно, то все должно заработать.

Здравствуйте.
Вот есть, к примеру, у вас связка: веб-сервер Apache, интерпретатор для выполнения приложений на PHP и СУБД MySQL. Обычно с этим набором мы и имеем дело. Это "инфраструктура" для работы сайта. Файлы и каталоги движка сайта приведены у вас на скриншоте.
Если нет уверенности в процессе установки (развертывания) сайта, то, конечно, удобно тренироваться на локальном веб-сервере. Но и в случае с хостингом - не страшно. Ошибки можно исправить. Ничего лишнего вам, все равно, сделать не позволят (не дадут соответствующих прав).
Файлы движка сайта (так сказать, программа) - одна история. База данных, где будет хранится контент (наполнение) сайта: логины, пароли, разделы сайта, сообщения и прочее - другая история. Не путайте эти сущности. С точки зрения сайта, а также веб-мастера, локальная (тестовая) машина ничем не отличается от хостинга. Просто один компьютер - у вас дома, а другой - у хостинг-провайдера.
В самом простом случае или когда нужно что-то откорректировать на сайте, файлы и каталоги просто копируются, с сохранением структуры. Например: файл localhost/favicon.ico кладется в корень хостинга так, чтобы он был доступен по адресу blablabla.ru/favicon.ico . Допустим, файлы скопированы. Далее, нужно будет как-то подключить сайт к БД. Каким образом? Вообще, я смотрю, что у вас движок на локалхосте находится в установленном (распакованном) виде. Как, после распаковки, подключить данный (в вашем примере) движок к БД, я не знаю. Надо знать его название и искать документацию. Если таковой вариант действий возможен в принципе. Мне, к примеру, не приходилось подобным заниматься.
А так, наиболее простой способ установки движка сайта - из дистрибутива (через установщик). Если планируете ставить движок с нуля. Смотрите внимательно, не замените свои файлы header, footer и т. д., если вы вносили в них нужные правки! Т. к. установщик заменит их своими версиями. Тогда сначала ставите движок, а потом заменяете отдельные файлы.
PHPMA нужен для работы с БД, а не для установки сайта. Это инструмент для иных задач. Да и без сведений о названии и пароле доступа к БД он вам ничего не даст.

Название БД и пароль должны быть выданы веб-мастеру заранее, еще до начала установки, вместе с паролем от хостинга. Вы сами не создаете БД (я не уверен что такое доступно среднестатистическому веб-мастеру). Т. к. из большой (общей) БД хостер выделяет какую-то БД (часть), имеющую свое, уникальное имя. Вот в этой, своей "песочнице", мы и работаем. Таким образом, ресурсы одних клиентов хостера отделены от ресурсов других клиентов.

PHP позволяет решить эту задачу множеством способов, использовать готовый шаблонизатор, например Twig.

Или реализовать свой с использованием функций ob_start() и ob-get-clean(): создаете файлы index.php и functions.php, каталог templates в котором будут храниться все файлы шаблонов. В каталоге templates создаете файлы: layout.php, header.php, footer.php, content.php.

Файл functions.php:

/**
 * Функция загрузки шаблона
 * 
 * @param string $template Путь до файлов шаблона
 * @param mixed[] $data Данные для подстановки в шаблон
 * @return string Возвращает готовый код шаблона
 */
 function render_template($template, $data = []) {
     ob_start();
     if (file_exists($template)) {
         extract($data);
         require($template);
     } else {
         print('Нет файла шаблона: '.$template);
     }
     $html = ob_get_clean();
     return $html;
 }

Файл index.php:

require_once __DIR__ .  '/functions.php';

$header = render_template('templates/header.php', ['title' => 'Главная страница']);
$footer= render_template('templates/footer.php');
$content = render_template('templates/content.php');
$page_layout = render_template('templates/layout.php',  
                               ['header' => $header, 'footer' => $footer,  'content' => $content]);
print($page_layout);

Файл templates/header.php:

<head>
<title><?=$title?></title>
</head>

Файл templates/layout.php (в котором вместо <?=$header?> будет выводиться содержимое из файла templates/header.php и т.д.):

<!DOCTYPE html>
<html lang="ru">
<?=$header?>
<body>
<?=$content?>
<?=$footer?>
</body>
</html>