Как перенести локальный WordPress на живой сервер

Фрагмент интерфейса WordPress и локальной среды разработки

Вводная: многие разработчики начинают сайт локально — это удобно для разработки и тестирования. Когда приходит время «выйти в прод», нужно перенести файлы и базу данных на живой сервер. Ниже — подробная пошаговая инструкция, советы по отладке, альтернативные подходы и контрольные списки для разработчика и администратора хостинга.

Требования

Перед началом убедитесь, что у вас есть:

Локальная рабочая копия сайта и доступ к файлам (локальная папка с WP).
Доступ к локальной базе данных через phpMyAdmin (или другой менеджер баз).
Аккаунт хостинга и домен, привязанный к нему (DNS уже настроен или вы знаете, как это сделать).
FTP/SFTP-доступ к корню веб-сайта на хостинге (обычно public_html, httpdocs или www).
Имя базы данных, пользователь и пароль для аккаунта на хостинге.

Важно: если экспорт вашей базы больше ~2 МБ и у хостинга стоит ограничение на импорт через веб-интерфейс, придется делить дамп или использовать альтернативы (см. раздел «Альтернативные подходы»).

Подготовка

Запишите все параметры локальной и удалённой баз данных: имя БД, имя пользователя, пароль, хост (обычно localhost на хостингах).
Зафиксируйте локальные URL и шаблоны путей к медиафайлам. Примеры форматов:
- Windows-путь: c:/sites/wordpress/wp-content/uploads/2011/05/test.jpg
- Локальный URL: http://localhost/wordpress
- Прод URL: https://example.com
Сохраните резервную копию локального проекта (архив папки и дамп БД). Всегда работайте с копиями.

Экспорт базы данных

Откройте phpMyAdmin локального сервера и выберите нужную базу.
Во вкладке “Экспорт” выберите:
- все таблицы (Select All),
- опцию “Добавлять DROP TABLE / VIEW / FUNCTION / PROCEDURE / EVENT”,
- “Сохранить как файл” и задайте понятное имя (например export.sql).
Скачайте файл и сделайте его копию перед изменениями.

Скриншот экспорта из phpMyAdmin

Совет: если дамп слишком большой для веб-импорта, сожмите его в ZIP. Проверьте лимиты хостинга на импорт.

Корректировка путей и URL в SQL-файле

Это ключевой этап. Откройте экспортированный .sql в удобном текстовом редакторе (Sublime, VS Code, Notepad++).

Что менять:

Все вхождения локального URL (например http://localhost/wordpress) → ваш прод URL (https://example.com).
Абсолютные файловые пути Windows (c:/sites/…) → относительные пути или адреса вида https://example.com/wp-content/…

Рекомендации по замене:

Сначала выполните поиск (Find) по старому URL и проверьте совпадения.
Используйте массовую замену (Replace All) только после проверки первых нескольких совпадений.
Обратите внимание на слэши в конце: https://example.com и https://example.com/ — соблюдайте консистентность.

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

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name IN ('siteurl','home');

Обратите внимание: некоторые плагины и метаполя содержат сериализованные PHP-строки, в которых изменение длины строки (например при замене URL) может повредить данные. Для безопасной замены сериализованных данных используйте специализированные инструменты или WP-CLI (см. раздел «Альтернативные подходы»).

Редактирование SQL-файла в текстовом редакторе

Загрузка файлов на сервер

Подключитесь к хостингу по FTP/SFTP.
В корневую папку сайта (обычно public_html или httpdocs) загрузите все файлы вашего локального WordPress.
- Если вы устанавливаете в корень — загружайте содержимое папки с WP, чтобы внутри были wp-content, wp-admin, wp-includes.
- Для экономии времени на больших сайтах можно загружать только папку wp-content (темы, плагины, медиа), если на хостинге вы установили чистый WordPress через панель.

Важно: Windows-пути и метаданные не копируются — проверьте права доступа к файлам после загрузки.

Предупреждение: на Windows возможны проблемы с правами. После развертывания запустите проверку прав доступа и установите минимальные безопасные права (обычно 755 для папок и 644 для файлов). Установка плагина безопасности может помочь автоматизировать проверку.

Примечание: у некоторых провайдеров (например у GoDaddy) удобнее сначала установить WordPress через панель управления, а затем загрузить только wp-content и импортировать базу. Это упрощает настройки соединения с БД на стороне хостинга.

Импорт базы данных на хостинге

Если ваш SQL-файл меньше лимита — сожмите его в ZIP (если требуется) и в phpMyAdmin хостинга откройте вкладку “Импорт”.
Выберите подготовленный SQL или ZIP и выполните импорт.
Если импорт завершился с ошибками по размеру, делите дамп на части или используйте альтернативы (см. дальше).

Правка wp-config.php

Откройте wp-config.php в корне сайта и проверьте/измените строки с параметрами базы:

DB_NAME — имя базы данных;
DB_USER — имя пользователя базы;
DB_PASSWORD — пароль;
DB_HOST — хост базы (обычно localhost, реже ip или специальный хост провайдера).

Сохраните файл и загрузите обратно на сервер.

Файл wp-config.php в корне проекта

Проверка и отладка

Откройте сайт по домену и проверьте главную страницу.
Войдите в админку (/wp-admin) и проверьте настройки → Общие (Site URL и WordPress Address).
Проверьте медиафайлы и несколько страниц/постов.
Если картинки не отображаются — проверьте пути в базе и права на папку wp-content/uploads.
Частые ошибки при импорте:
- “Error establishing a database connection” — проверьте данные в wp-config.php.
- 500 Internal Server Error — проверьте .htaccess и права файлов.
- Пробелы или сломанные плагины — временно переименуйте папку plugins и активируйте плагины по одному.

Критерии приёмки

Главная и несколько ключевых страниц открываются без ошибок;
Изображения и медиа доступны и корректно отображаются;
Админка доступна и логин работает;
Формы и важный функционал (корзина, поиск, авторизация) протестированы.

Альтернативные подходы

Использовать WP-CLI: безопасно обрабатывать сериализованные данные через wp search-replace. Требует SSH-доступа.
Использовать плагины миграции (Duplicator, All-in-One WP Migration): автоматизируют экспорт/импорт и корректно обрабатывают сериализацию. Удобно для менее технических пользователей.
Ручная установка WordPress на хостинге через панель, затем загрузка только wp-content и импорт базы.

Когда ручная миграция не подходит

Очень большие базы данных (гигабайты) — веб-интерфейс phpMyAdmin может не справиться.
Сложные мультиязычные конфигурации или сайты с кастомными таблицами/плагинами, которые хранят сериализованные данные в особых форматах — лучше использовать WP-CLI или тестировать на стейджинге.

Ментальные модели и полезные эвристики

«Файлы — это интерфейс, база — данные»: если у вас большинство изменений — плагины/темы — переносите wp-content; если содержимое — экспортируйте БД.
Проверяйте сначала по поддомену или временной директории, прежде чем менять DNS.
Всегда имейте исходный дамп: легче повторить миграцию, чем устранять ошибочные правки в продакшне.

Контрольные списки по ролям

Для разработчика:

Сделать резервную копию локального проекта.
Экспортировать базу и архивировать файлы.
Подготовить и проверить массовую замену URL.
Протестировать сайт локально после замен.

Для администратора хостинга:

Подготовить базу данных и пользователя.
Проверить квоты и лимиты импорта по phpMyAdmin.
Настроить SSL и права на файлы.

Мини-методология миграции (шаги на одной странице)

Резерв: архив локальной папки + дамп базы.
Экспорт БД через phpMyAdmin.
Резервная копия SQL.
Поиск/замена URL и путей в SQL.
FTP: загрузка wp-content и остальных файлов.
Импорт SQL на хостинге.
Обновление wp-config.php.
Проверка и исправления.

Пример команд и сниппетов

SQL для обновления siteurl и home (выполнять в phpMyAdmin или в MySQL):

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'home';

WP-CLI команда для безопасной массовой замены (если есть SSH):

wp search-replace 'http://localhost/wordpress' 'https://example.com' --skip-columns=guid

План отката и runbook при ошибке

Если сайт сломался после импорта:
1. Вернуть старый wp-config.php (если изменяли) и базу из резервной копии.
2. Переименовать папку plugins — вернёт доступ к админке, если проблема в плагине.
3. Откатить .htaccess к дефолтному варианту WordPress.

Частые ошибки и их решения

Сломанные изображения: проверьте правильность ссылок и наличие файлов в wp-content/uploads.
Ошибки сериализации: используйте WP-CLI или плагин миграции.
Ограничение размера импорта: разбейте дамп на части или используйте SSH/SCP.

Безопасность и права

Не храните пароли в открытом виде в общедоступных местах.
Права: папки 755, файлы 644, wp-config.php — 600 или 640 при возможности.
Включите SSL и обновите ссылки на https в базе и настройках.

Локальные особенности и подводные камни

Провайдеры типа GoDaddy могут иметь нестандартные ограничения или интерфейсы — иногда проще установить WordPress через панель, чем вручную подключать базу.
На некоторых хостингах имя префикса таблиц в базе может отличаться — убедитесь, что wp-config.php содержит правильный $table_prefix.

Краткая справка терминов

Дамп (экспорт) — текстовый файл с SQL-инструкциями для воссоздания базы.
Сериализация — способ хранения структур в виде строки (важно при замене URL).
WP-CLI — инструмент командной строки для управления WordPress.

Модель принятия решений

flowchart TD
  A[Готовы параметры хоста?] -->|Да| B[Экспорт БД]
  A -->|Нет| Z[Настроить хостинг]
  B --> C[Правка URL в SQL]
  C --> D{SQL > лимит импорта?}
  D -->|Нет| E[Импорт в phpMyAdmin]
  D -->|Да| F[Использовать SSH или разбить дамп]
  E --> G[Загрузка файлов по FTP]
  F --> G
  G --> H[Правка wp-config.php]
  H --> I[Тестирование]
  I --> J{Ошибки?}
  J -->|Нет| K[Выход в продакшн]
  J -->|Да| L[Откат и отладка]

Итог

Перенос локального WordPress на живой сервер — пошаговая, воспроизводимая задача. Основные риски связаны с некорректной заменой URL и ограничениями на импорт. Используйте резервные копии, проверяйте сериализованные данные и, при возможности, применяйте инструменты, которые автоматизируют корректную замену ссылок.

Если после миграции остались вопросы — опишите конкретную проблему (ошибка, логи, что проверили) и места, где процесс остановился. Это ускорит диагностику и позволит дать точные рекомендации.