Перенос WordPress с локального сервера на хостинг

Схема переноса сайта с локального сервера на хостинг

В этой инструкции подробно показан процесс переноса сайта, разработанного локально (локальный сервер, например XAMPP, MAMP или WAMP), на реальный хостинг. Принципы остаются теми же для большинства CMS: экспорт базы, корректировка путей/URL, перенос файлов и настройка соединения с базой на сервере.

Требования

Рабочая локальная инсталляция WordPress с доступом к файлам и базе данных через phpMyAdmin или аналог.
Доступ к хостингу по FTP/SFTP и к phpMyAdmin на боевом сервере (или доступ к панели управления хостингом).
Домен, привязанный к хостингу (предполагается, что вы уже сделали это).
Если база очень большая (несколько десятков МБ и выше), этот способ может не подойти — потребуется загрузка через SSH/командную строку или использование плагинов/инструментов, поддерживающих большие дампы.

Важно: ограничение по размеру импорта в phpMyAdmin часто около 2 МБ–8 МБ в зависимости от провайдера. Это ограничение относится к текстовому дампу базы, не к общему объёму файлов (wp-content и т. п.).

1. Подготовка

Запишите данные доступа к локальной и боевой БД: имя базы, имя пользователя и пароль.
Зафиксируйте локальный URL сайта (например, http://localhost или http://mysite.test) и абсолютные пути к файлам (например, C:/sites/wordpress/wp-content/uploads/2011/05/test.jpg). Запишите всё до каталога wp-content — именно эти префиксы будут заменяться.
Сделайте резервную копию всех локальных файлов и создайте копию экспортируемого SQL‑файла перед правками.

Коротко: знание текущих URL/путей и данных БД экономит часы на отладке.

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

Откройте phpMyAdmin локально и выберите нужную базу.
На вкладке Экспорт выберите полный экспорт всех таблиц.
Отметьте “Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT” (если доступно), чтобы импорт мог перезаписать существующие таблицы.
Выберите “Save as file” и задайте запоминаемое имя (например, export.sql).
Нажмите Go — сохраните файл локально.

Экспорт базы в phpMyAdmin

Совет: если у вас много данных, используйте экспорт по частям или командную строку (mysqldump). Для типичных небольших сайтов обычный экспорт работает хорошо.

3. Корректировка путей и URL в SQL

Это самая чувствительная часть. Откройте экспортированный SQL‑файл в хорошем текстовом редакторе (VS Code, Sublime Text, Notepad++).

Сделайте резервную копию SQL‑файла.
Найдите все вхождения локального домена/пути (поиск по “localhost”, “http://mysite.test”, или по пути “C:/sites/wordpress”).
Внимательно выполните глобальную замену: замените локальный URL на боевой (например, http://localhost → https://example.com), а абсолютные файловые пути (C:/sites/…) — на относительные или на URL сайта (https://example.com/wp-content/…). Учитывайте слэши в конце.
Не меняйте автоматически сериализованные данные, если используете простую замену текста — сериализованные строки содержат длину строки и такая замена может сломать данные. Для корректной работы с сериализацией используйте WP‑CLI команду search-replace или специализированный скрипт (например, interconnect/it Search Replace DB) на сервере.

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

Поиск и замена путей в SQL

Когда закончите, сохраните изменённый SQL и сожмите его (zip), если это требуется для загрузки через phpMyAdmin.

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

Откройте FTP/SFTP‑клиент (FileZilla, WinSCP) и подключитесь к серверу.
Перейдите в корневую папку веб-сайта: чаще всего public_html или httpdocs.
Загрузите все файлы локальной установки WordPress в корень (wp‑admin, wp‑includes, wp‑content и файлы в корне).
Если у вас есть уже установленная WordPress через панель хостинга, можно загружать только содержимое папки wp-content (темы, плагины, загрузки) и затем импортировать базу.

Important: На Windows имена файлов чувствительны к регистру при загрузке на Linux-хостинги. Также проверьте права доступа после загрузки.

Note: На некоторых провайдерах (например, GoDaddy) удобнее сначала установить WordPress через панель, затем загружать только wp-content и импортировать базу, чтобы избежать проблем с конфигурацией.

5. Импорт базы данных на боевой сервер

Откройте phpMyAdmin на хостинге и выберите пустую (или готовую к перезаписи) базу данных.
На вкладке Импорт выберите ZIP/SQL файл, который вы подготовили.
Нажмите Go и дождитесь завершения.

Если файл превышает лимит импорта, используйте:

разбивку дампа на части;
загрузку через SSH (mysql < dump.sql);
плагин миграции, поддерживающий большие файлы.

6. Редактирование wp-config.php

В корне сайта откройте wp-config.php.
Обновите следующие параметры:

DB_NAME — имя базы данных на хостинге
DB_USER — пользователь БД
DB_PASSWORD — пароль
DB_HOST — хост базы данных (часто localhost, иногда другой адрес)

При необходимости включите отладку (define(‘WP_DEBUG’, true)) временно, чтобы увидеть ошибки.

Редактирование wp-config.php в корне сайта

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

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

Проверьте:

Открывается ли главная страница и внутренние страницы.
Работают ли изображения и медиа в записях (проверка путей к wp-content/uploads).
Работают ли ссылки в меню и виджеты.
Авторизация в админке (wp-admin) и работа плагинов.

Если нужно, выполните массовую замену URL в живой базе с помощью WP‑CLI: wp search-replace ‘http://localhost’ ‘https://example.com’ –all-tables — этот метод безопаснее при работе с сериализованными данными.

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

500 Internal Server Error: проверьте права файлов (обычно каталоги 755, файлы 644) и .htaccess. Отключите плагины переименованием папки plugins.
Белый экран (White Screen of Death): включите WP_DEBUG, проверьте логи PHP и памяти; иногда достаточно увеличить memory_limit.
Изображения не отображаются: проверьте пути к файлам и права доступа; убедитесь, что wp-content/uploads загружен полностью.
Некорректные URL в виджетах/настройках темы: используйте безопасный search-replace.

Когда этот метод не подходит (контрпримеры)

Очень большая база данных (>100 МБ) и ограничение импорта — лучше использовать SSH/CLI или плагин, поддерживающий chunked uploads.
Сложные сериализованные структуры и множество плагинов, которые хранят данные в собственных форматах — рекомендуются WP‑CLI или специализированные миграционные плагины.

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

Плагины: Duplicator, All‑in‑One WP Migration, UpdraftPlus — автоматизируют экспорт/импорт и часто корректно обрабатывают сериализацию.
WP‑CLI: полноценный инструмент для экспорта/импорта, search-replace и управления сайтами через SSH.
rsync + mysqldump: для опытных — копирование файлов по SSH и импорт дампа через mysql.

Ментальная модель переноса

Файлы (wp‑core + темы + плагины + загрузки) — это «контент и код».
База данных — это «настройки, записи, связи».
wp-config.php соединяет «код» и «данные» в среде хостинга.

Перенос — это синхронизация этих трёх компонент и корректировка путей/URL под новую среду.

Ролевые чек‑листы

Для разработчика:
- Сделать экспорт SQL и резервную копию файлов.
- Подготовить список плагинов и версий.
- Протестировать сайт локально в режиме продакшн (https, постоянные ссылки).
Для администратора хостинга:
- Создать БД и пользователя, настроить права.
- Настроить домен и SSL (если нужно).
- Проверить лимиты PHP и права файлов.
Для контент‑менеджера:
- Проверить отображение контента, изображения и ссылки.
- Обновить внутренние ссылки и карту сайта.

Мини‑SOP (пошаговая процедура)

Делать резервные копии исходных файлов и БД.
Экспортировать базу и подготовить её для замены URL.
Выполнить корректную замену путей (учитывая сериализацию).
Загрузить файлы на хостинг в public_html/httpdocs.
Импортировать базу на боевой сервер.
Обновить wp-config.php.
Проверить сайт, права и безопасность.

Мера безопасности и жесткая настройка

Проверьте права: каталоги 755, файлы 644, wp-config.php 600 или 640 при возможности.
Установите плагин безопасности (Wordfence, iThemes Security) и просканируйте сайт.
Отключите отображение ошибок на продакшене.
Включите HTTPS (настройка SSL), перенаправление с HTTP на HTTPS.

Приватность и соответствие GDPR (если есть данные пользователей)

При переносе убедитесь, что база не содержит лишних экспортируемых персональных данных.
Храните дампы в защищённых местах и удаляйте временные архивы после переноса.
Убедитесь, что хостинг соответствует требованиям безопасности для хранения персональных данных.

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

Главная и внутренние страницы открываются корректно.
Изображения и медиа доступны и отображаются.
Авторизация в админке работает.
Производительность и время отклика находятся в ожидаемых пределах.
SSL установлен и перенаправление настроено.

Диаграмма принятия решения при выборе метода миграции

flowchart TD
  A[Нужна миграция WordPress?] --> B{База < 8 МБ и нет сериализации?}
  B -- Да --> C[Экспорт SQL + замена путей + FTP + импорт]
  B -- Нет --> D{Есть SSH доступ?}
  D -- Да --> E[Использовать WP-CLI / mysqldump + rsync]
  D -- Нет --> F[Использовать плагин миграции 'Duplicator, All-in-One']
  E --> G[Тестирование и проверки]
  C --> G
  F --> G
  G --> H[Готово]

Итоги

Перенос локального WordPress‑сайта на хостинг — это последовательность операций: экспорт базы, корректировка путей/URL, загрузка файлов, импорт базы и настройка wp-config.php. Для небольших сайтов этот процесс выполним вручную, для больших и сложных — используйте WP‑CLI или плагины миграции. Всегда делайте резервные копии и тестируйте сайт после переноса.

Если столкнулись с проблемами — опишите шаги, которые вы выполняли, ошибки из логов и поведение сайта; это поможет быстрее найти причину. Также можно задать вопрос в технической поддержке хостинга или в профильном сообществе.

Краткая памятка (чек‑лист):