Migrate from Google Sites to WordPress: A Comprehensive Guide

Transitioning a production web property from a proprietary, closed-ecosystem platform like Google Sites to a self-hosted, extensible WordPress installation requires a rigorous, engineering-focused approach. Google Sites abstracts server infrastructure, database management, and file storage behind a simplified user interface, but this abstraction fundamentally limits extensibility, granular security configurations, and advanced SEO execution. Moving to WordPress reclaims root access over the application layer, database schemas, and web server configurations.

This technical migration guide outlines the architectural requirements, data mapping workflows, command-line operations, and post-migration hardening procedures necessary to execute a seamless transition without compromising data integrity, search engine equity, or site security.

Problem Statement & Architectural Impact

Google Sites operates as a multi-tenant SaaS application hosted entirely within Google’s cloud infrastructure. Site owners interact with an abstracted DOM editor where content is stored inside proprietary Google Drive data structures. This architectural limitation creates severe technical constraints for growing organizations:

• Absence of Direct Database Access: Administrators cannot execute SQL queries, optimize database indexes, or perform programmatic bulk updates via WP-CLI or direct database connections.
• Restricted Server-Level Configurations: Customization of .htaccess, Nginx server blocks, HTTP response headers, content security policies (CSP), and server-side caching mechanisms is entirely unavailable.
• Limited API and Webhook Integrations: Integrating complex enterprise resource planning (ERP) systems, customer relationship management (CRM) platforms, or custom headless architectures is bottlenecked by the lack of direct backend hooks.
• Rigid URL and Sitemaps Architecture: URL structures enforce nested parameters tied to Google’s internal routing, restricting the implementation of custom regex-based 301 redirects and advanced XML sitemap schemas.

The business and security consequences of maintaining a production presence on an unyielding platform include diminished organic search visibility due to rigid SEO metadata controls, inability to implement zero-trust network access controls, and vulnerability to business logic interruptions when scaling beyond simple informational pages. Migrating to a self-hosted WordPress stack resolves these technical debt issues but demands strict adherence to software migration best practices.

Root Cause Analysis & Data Extraction Architecture

Because Google Sites lacks a native export utility capable of serializing content into WordPress-compatible XML (WXR) or direct database tables, the migration relies on a hybrid scraping, DOM parsing, and manual reconstruction methodology. Understanding the underlying HTTP request lifecycle and content rendering mechanisms of Google Sites dictates how data must be harvested.

When a browser requests a Google Sites page, the platform serves a heavily client-side-rendered HTML document loaded via dynamic JavaScript bundles hosted on Google’s content delivery network. Automated scraping tools must account for dynamic asset paths, iframe embeddings, and restricted Google Drive image URLs. Failure to extract and re-host static assets locally during the migration phase leads to broken references when Google Sites instances are eventually decommissioned.

The architectural target—a LEMP (Linux, Nginx, MySQL, PHP) or LAMP stack running WordPress—processes requests through the PHP application runtime, resolving permalinks via database lookups in the wp_posts and wp_postmeta tables. Consequently, data mapped from Google Sites must be structured to match WordPress custom post types, hierarchical page relationships, and taxonomy terms.

Step-by-Step Implementation & Migration Procedures

Step 1: Provisioning the Secure WordPress Environment

Before initiating data migration, construct a hardened server environment. Avoid shared hosting tiers that restrict PHP execution time, memory limits, and command-line access. Deploy a dedicated Virtual Private Server (VPS) or cloud instance running Ubuntu Server 22.04 LTS, Nginx, MariaDB, and PHP 8.2+.

Initialize the server and configure the foundational LEMP stack using the following administrative terminal commands:

# Update system packages and install required dependencies
sudo apt update && sudo apt upgrade -y
sudo apt install nginx mariadb-server php8.2-fpm php8.2-mysql php8.2-xml php8.2-mbstring php8.2-curl php8.2-zip unzip certbot python3-certbot-nginx -y

# Secure MariaDB installation
sudo mysql_secure_installation

# Create the WordPress database and privileged user
sudo mysql -u root -p
CREATE DATABASE wordpress_prod CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'StrongCryptographicPasswordHere!987';
GRANT ALL PRIVILEGES ON wordpress_prod.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Download and configure WordPress via WP-CLI to ensure clean installation parameters and optimal file permission hierarchies:

# Create web root and download WordPress core
sudo mkdir -p /var/www/html/mysite
cd /var/www/html/mysite
sudo wget https://wordpress.org/latest.tar.gz
sudo tar -xzf latest.tar.gz --strip-components=1
sudo rm latest.tar.gz

# Configure ownership and restrictive directory permissions
sudo chown -R www-data:www-data /var/www/html/mysite
sudo find /var/www/html/mysite -type d -exec chmod 755 {} \;
sudo find /var/www/html/mysite -type f -exec chmod 644 {} \;

# Install WP-CLI and generate wp-config.php
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

wp config create --dbname="wordpress_prod" --dbuser="wp_user" --dbpass="StrongCryptographicPasswordHere!987" --dbhost="localhost" --dbprefix="wp_927x_" --path=/var/www/html/mysite --allow-root
wp core install --url="https://example.com" --title="Migrated Production Site" --admin_user="sysadmin_lead" --admin_password="ComplexAdminPassword123!" --admin_email="[email protected]" --path=/var/www/html/mysite --allow-root

Step 2: Content Inventory & DOM Parsing Strategy

Because automated programmatic exports from Google Sites are unavailable, execute a thorough structural audit of the source site. Map every URL path to a corresponding spreadsheet containing the following fields:

• Source URL (Google Sites Path): e.g., https://sites.google.com/view/mycompany/services/consulting
• Target Slug (WordPress Permalinks): e.g., /services/consulting/
• Page Hierarchy: Parent-Child relationships determining WordPress page nesting.
• Asset Manifest: Inventory of embedded images, PDF documents, and external links.

For large sites, utilize automated web-scraping utilities (such as Screaming Frog SEO Spider or custom Python BeautifulSoup scripts) to harvest the raw HTML content of every page on the Google Sites domain. This prevents manual copy-pasting errors and captures hidden structural metadata.

Step 3: Content Ingestion and Database Population via WP-CLI

Once the source HTML and assets are extracted, clean the markup to remove Google-specific DOM wrappers, inline styles, and tracking scripts. Convert the cleaned content into clean HTML or Markdown blocks compatible with the WordPress Gutenberg editor.

To ingest content programmatically at scale, write a custom PHP script executed via WP-CLI that reads your structured content array and inserts posts directly into the database using wp_insert_post(). Create an ingestion script named import.php:

<?php
/**
 * Programmatic WordPress Content Ingestion Script
 * Execute via: wp eval-file import.php
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

$pages = [
    [
        'title'   => 'Home',
        'slug'    => 'home',
        'content' => '<h1>Welcome to Our New Secure Platform</h1><p>Content migrated successfully from Google Sites.</p>',
        'parent'  => 0,
    ],
    [
        'title'   => 'Services',
        'slug'    => 'services',
        'content' => '<h2>Our Core Offerings</h2><p>Detailed technical services overview.</p>',
        'parent'  => 0,
    ],
];

foreach ( $pages as $page_data ) {
    $post_arr = [
        'post_title'   => wp_strip_all_tags( $page_data['title'] ),
        'post_name'    => $page_data['slug'],
        'post_content' => $page_data['content'],
        'post_status'  => 'publish',
        'post_type'    => 'page',
        'post_parent'  => $page_data['parent'],
        'post_author'  => 1,
    ];

    $post_id = wp_insert_post( $post_arr );

    if ( is_wp_error( $post_id ) ) {
        echo "Failed to insert page: " . $page_data['title'] . "\n";
    } else {
        echo "Successfully inserted page ID: {$post_id} - {$page_data['title']}\n";
    }
}

Execute the ingestion script via the terminal interface:

wp eval-file import.php --path=/var/www/html/mysite --allow-root

Step 4: Implementing Permanent 301 Redirects

Preserving search engine optimization (SEO) equity requires configuring explicit 301 (Moved Permanently) redirects for every altered URL structure. Since Google Sites utilizes rigid URL paths, visitors and search engine bots attempting to access legacy URLs will encounter 404 Not Found errors unless server-level or plugin-level redirection rules are enforced.

Configure Nginx server blocks to handle deterministic regex matching for legacy paths, or implement a robust redirection management plugin within WordPress. For Nginx-level redirection (preferred for optimal performance), insert the following directives into your server block configuration file (/etc/nginx/sites-available/mysite):

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    root /var/www/html/mysite;
    index index.php index.html index.htm;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Legacy Google Sites URI Redirect Mappings
    location ~* ^/view/mycompany/services/(.*)$ {
        return 301 https://example.com/services/$1;
    }

    location ~* ^/view/mycompany/about-us$ {
        return 301 https://example.com/about/;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

Test the Nginx configuration syntax and reload the service to apply changes without downtime:

sudo nginx -t
sudo systemctl reload nginx

Production Hardening & Edge Cases

Self-hosted WordPress environments present an expanded attack surface compared to managed SaaS platforms like Google Sites. Deploying a newly migrated site to production without implementing aggressive hardening measures exposes the application to brute-force attacks, SQL injection attempts, remote code execution (RCE), and DDoS vectors.

File System Permissions and Hardening wp-config.php

Lock down write permissions across the WordPress core directory structure. Only specific directories—primarily wp-content/uploads—require write access by the web server user (www-data). Apply strict permissions across the stack:

# Restrict all files to read-only for web server, write restricted to root
sudo chown -R root:www-data /var/www/html/mysite
sudo find /var/www/html/mysite -type d -exec chmod 750 {} \;
sudo find /var/www/html/mysite -type f -exec chmod 640 {} \;

# Grant write permissions exclusively to the uploads directory
sudo chown -R www-data:www-data /var/www/html/mysite/wp-content/uploads
sudo find /var/www/html/mysite/wp-content/uploads -type d -exec chmod 755 {} \;
sudo find /var/www/html/mysite/wp-content/uploads -type f -exec chmod 644 {} \;

Move the wp-config.php file one directory level above the web root to prevent direct browser exposure if PHP execution is misconfigured:

sudo mv /var/www/html/mysite/wp-config.php /var/www/html/wp-config.php
sudo chmod 400 /var/www/html/wp-config.php
sudo chown root:www-data /var/www/html/wp-config.php

Instruct WordPress to locate the configuration file by adding a reference pointer inside the web root wp-load.php or ensuring the upstream bootstrap handles the directory shift, or keep the file protected via Nginx access rules:

# Add to Nginx server block to block direct access to wp-config.php
location = /wp-config.php {
    deny all;
}

Database Security and Credential Rotation

Never retain default database prefixes (such as wp_). During WP-CLI installation, a randomized prefix (e.g., wp_927x_) was enforced to mitigate automated SQL injection enumeration attacks. Furthermore, enforce strict SSL/TLS encryption for all database connections by defining encryption parameters inside wp-config.php:

define( 'MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL );

Caching Conflicts and Performance Optimization

Unlike Google Sites, which leverages Google’s global edge infrastructure automatically, WordPress performance relies on object caching and page caching layers. Implement Redis or Memcached for database object caching to minimize MariaDB query latency under high traffic loads.

Install and configure Redis via terminal:

sudo apt install redis-server php8.2-redis -y
sudo systemctl enable redis-server
sudo systemctl start redis-server

Configure WordPress to utilize the Redis backend by installing the Object Cache Pro or Redis Object Cache plugin, and define connection constants in wp-config.php:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_CLIENT', 'phpredis' );
define( 'WP_REDIS_DATABASE', 0 );

Diagnostic Verification & Post-Migration Checklist

Before updating DNS records to point the production domain to the new WordPress server, execute a comprehensive validation audit across staging endpoints. Verify application functionality, security posture, and search engine crawlability against the following verification matrix:

Once all validation checks return positive metrics, modify the DNS A and AAAA records at your domain registrar to point the apex domain and www subdomain to the public IP address of the new hardened WordPress server. Monitor propagation using global DNS resolution tools and keep the Google Sites instance active in a restricted, read-only state for a minimum of fourteen days to ensure no archival data or unmapped long-tail URLs were omitted during the migration lifecycle.