Анна

Как написали выше, все возможно. Вам если не обращаться к 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>

Надеюсь, что употребляя словосочетание "купить домен", Вы понимаете, что на самом деле Вы покупаете услугу администрирования доменного имени, то есть право внести в БД техрегистратора нужную Вам инфу :)

У хостера домены берут те, кто не хочет морочиться - хостер обычно всячески этому способствует.
У регистратора - те, кто понимает, что делает и зачем он это делает. Ну и кроме того, домен - далеко не всегда сайт :)

вы уверены что непроиндексированные страницы существуют? Очень часто, а для некоторых причин неиндексации в большинстве случаев, непроиндексированные страницы не существуют. Пересмотрите, если есть, карту сайта, обновите её. Есть сервисы для создания карты сайта онлайн. Проверьте файл robots.txt. Если есть непроиндексированные страницы с причиной блокировки в robots.txt, сделайте пробный чистый robots. В смысле не пустой, а с записью только User-agent: *
Allow: /

Sitemap: ... sitemap.xml

Если ваш сайт на wordpress, то это скорей всего сео плагин создаёт корявые ссылки. Если указана причина Страница с переадресацией, то скорее всего этих страниц не существует. Вернее такая то страница допустим есть , но адрес к ней несуществующий. К примеру есть страница урл сайта/страница такая-то, а урл с причиной переадресации имеет урл урл сайта/категория такая-то/страница такая-то. Чтобы посмотреть непроиндексированные адреса нажмите на причину. И увидите список. Если вы убедитесь что эти урлы не существуют, то просто проигнорируйте это, всё равно вы причину не найдёте, больше чем уверен. "почему требует canonical". Потому что есть канонический адрес. Опять таки, если каноникал, с переадресацией, копия, проверьте на правильность неиндекированного урла. В большинстве случаев эти урлы несуществуют.

Но остальные 13 нигде не показываются, и я даже не могу посмотреть, на каких страницах мне нужно исправлять что-то, чтобы они были проиндексированны.

Причин может быть миллион. От банального - не успел поисковик в индекс занести, до каких-нибудь ошибок или считает эти страницы малоценными. Может быть не настроена карта сайта или закрыты в robots.txt. Надо смотреть сам сайт, а еще лучше с доступом в SC.

Сделайте следующее. Возьмите урл каждой страницы и вручную загоните в SC. По ходу этого процесса гугл будет давать информацию об этих страницах: принимает их к индексации или нет. Если нет, то может сказать по какой причине.

Помогите, пожалуйста, разобраться, как найти эти страницы и исправить их.

Если вносили канониклы на сайт после добавления в SC, то изменения будут не сразу.

Я правильно понимаю, что 302 редирект и отсутствие нормального перехода в WhatsApp как-то связаны?

Нет. 302 redirect (Temporary redirect) - используется для временного перенаправления, сообщая, что целевая страница была перемещена временно, и краулеры не должны обновлять свои ссылки или кэш на постоянной основе. С другой стороны, 301 редирект (Moved Permanently) сообщает, что страница была перемещена навсегда, и краулеры должны обновить свои ссылки.

Почему ссылка на WhatsApp считается 302 редиректом, нормально ли это, и как это исправить?

Причина, по которой ссылка на WhatsApp обрабатывается как 302 редирект, может быть связана с тем, как WhatsApp управляет переходами, особенно если они ведут на внешнюю страницу или службу. Это может быть сделано для того, чтобы обеспечить гибкость в обработке запросов, например, при определении, установлен ли WhatsApp на устройстве пользователя. Если коротко - так задумано, нормально, никак.

нормально ли это, и как это исправить?

Это нормально, ничего исправлять не нужно.
(Но нужно изучить что такое редиректы)

Потому что если у вас ссылка вида https://wa.me/999999999999 (обычно такую используют), то происходит перенаправление на https://api.whatsapp.com/send/?phone=99999999999&t....

Почему 302, а не 301? Наверно потому что так решили реализовать разработчики вотсап.

Такое не только с вотсапом происходит. Тоже самое с Facebook и другими ссылками на сторонние сервисы.

Не надо это исправлять. Просто не обращать внимание.

Элементы массива должны быть в виде строк:

// wp_enqueue_script( 'slick', get_template_directory_uri() . '/assets/js/slick.min.js', array(jquery), 'null', true );
wp_enqueue_script( 'slick', get_template_directory_uri() . '/assets/js/slick.min.js', array('jquery'), null, true );

Зачем Вам 2 одинаковых slick.js?

// wp_enqueue_script( 'slick', get_template_directory_uri() . '/assets/js/slick.js', array(jquery), 'null', true );
wp_enqueue_script( 'slick', get_template_directory_uri() . '/assets/js/slick.min.js', array(jquery), 'null', true );

Стили хорошо бы подключать в шапке, а скрипты в подвале, вот финальный код:

<?php
add_action('wp_enqueue_scripts', function () {
    // styles
    wp_enqueue_style('style', get_template_directory_uri() . '/assets/css/style.css');
    wp_enqueue_style('media', get_template_directory_uri() . '/assets/css/media.css');
    wp_enqueue_style('slick-style', get_template_directory_uri() . '/assets/css/slick.css');

    // jquery
    wp_deregister_script('jquery');
    wp_register_script('jquery', 'https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js', [], null, true);
    wp_enqueue_script('jquery');

    // scripts
    wp_enqueue_script('slick', get_template_directory_uri() . '/assets/js/slick.min.js', ['jquery'], null, true);
    wp_enqueue_script('main', get_template_directory_uri() . '/assets/js/main.js', ['jquery'], null, true);
});

add_theme_support('post-thumbnails');
add_theme_support('title-tag');
add_theme_support('custom-logo');
?>

Наличие дополнительных микроразметок обычно не мешает

Добавлю пару моментов:

• Помимо гугловского валидатора есть ещё официальный: validator.schema.org. Проверять стоит и там, и там. У гугл немножко своя спецификация, и как выше уже отметили, какие-то поля он может считать обязательными, тогда как в общей спецификацией никаких проблем не будет.
  
• Вы используете RDFa. Её бы уже потихоньку заменять на JSON-LD. Формально RDFa считывается раньше, но ПС рекомендуют именно JSON-LD. Есть вероятность, что алго, учитывающий семантическую микроразметку, заточен теперь именно под этот синтаксис.
  

Выбвизор записывает не ролик поведения пользователя на сайте (не хватит места на планете записывать каждый визит), а копирует страницу и накладывает на нее с верху точки для движения курсором или сенсором.

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

А он их действительно может не видеть, т.к. Вы заменили верстку, а Метрика еще не успела скопировать обновленную страницу, но точки были получены и наложены уже с новой версии страницы.

Замечал еще моменты, когда Метрика не обновляла страницу из своего кэша после ее изменения. Предположительно, либо это баг, либо Метрика посчитала, что визуальные изменения не значительны для обновления кэша. Я изменил идентификатор у css и js на другой - и о чудо, через несколько часов, визиты пошли уже с обновленной страницы.