How to Remove “wordpress” From Your Site URL (Complete Technical Guide)

When WordPress is installed into a subdirectory named /wordpress, every public-facing URL carries that path segment — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — which undermines brand credibility and dilutes SEO equity. The fix is a controlled file migration combined with database URL updates: you move all WordPress core files from the subdirectory to the server's document root (public_html), update the WordPress Address and Site Address settings, regenerate rewrite rules, and issue 301 redirects for any indexed legacy URLs. No reinstallation is required.

This guide covers every technical layer of that process — file system operations, database string replacement, .htaccess rewrite logic, redirect strategy, and post-migration validation — including edge cases that cause silent failures in most tutorials.

Why WordPress Ends Up in a Subdirectory

Understanding the root cause prevents the same problem from recurring. The most common scenarios are:

• Installer defaults: Many one-click installers (Softaculous, Installatron) default to a subdirectory path if the user does not explicitly set the installation path to /.
• Staging-to-production promotion: A developer installs WordPress at /wordpress for testing and the site goes live without a path correction.
• Multi-site planning that never materialized: Someone anticipated running multiple CMSes under one domain and scoped WordPress to its own folder.
• cPanel auto-installer quirks: On VPS with cPanel environments, the installer sometimes appends the application name as a subdirectory unless overridden.

Regardless of origin, the migration procedure is identical.

Pre-Migration Checklist

Before touching a single file, complete every item on this list. Skipping any one of them is the leading cause of downtime during this operation.

• Full site backup: Archive both the file system and the MySQL database. Plugins like UpdraftPlus or Duplicator work well; so does a server-level snapshot if your VPS Hosting provider supports it.
• Database credentials on hand: You will need them if a manual wp-config.php edit becomes necessary.
• Maintenance mode active: Use a plugin or add define('WP_MAINTENANCE_MODE', true); temporarily to prevent writes during the migration window.
• PHP error logging enabled: Set WP_DEBUG_LOG to true in wp-config.php so any post-migration errors write to /wp-content/debug.log rather than appearing on screen.
• DNS TTL noted: If a DNS change is also involved, lower the TTL to 300 seconds at least one hour before starting.

Step 1: Move WordPress Files to the Document Root

The goal is to copy everything inside /public_html/wordpress/ directly into /public_html/ — not the folder itself, its contents.

Using an FTP Client (FileZilla)

1. Connect to your server over SFTP (port 22) rather than plain FTP to avoid credential interception.
2. Navigate to public_html/wordpress/.
3. Select all files and folders including hidden files. In FileZilla, enable View > Show Hidden Files to expose .htaccess and any .env files.
4. Drag the selection up one directory level into public_html/.
5. When prompted about overwriting index.php (if a placeholder exists in the root), confirm the overwrite.

Using the Command Line (Recommended for VPS)

If you have SSH access — which you should on any properly configured VPS Hosting or Dedicated Server environment — the command-line approach is faster and avoids FTP timeout issues on large installations:

# Navigate to the document root
cd /var/www/html/public_html

# Copy all contents (including hidden files) from the subdirectory to the root
cp -a wordpress/. .

# Verify the copy succeeded before deleting anything
ls -la | head -30

Do not delete the /wordpress directory yet. Leave it intact until the migration is fully validated. You can remove it in the final cleanup step.

Critical Edge Case: Symlinks and Absolute Paths in Plugins

Some plugins (particularly backup and security plugins) store absolute file paths in the database — for example, /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. These will break silently after the move. The database search-and-replace in Step 5 handles this, but you must include the wp_options table and any custom plugin tables in the replacement scope.

Step 2: Update WordPress Address and Site Address

WordPress stores two critical URL values in the wp_options table: siteurl (the WordPress Address, pointing to where WordPress core files live) and home (the Site Address, the URL visitors use to reach the site). Both must be updated.

Method A: WordPress Dashboard

1. Log in to yourdomain.com/wordpress/wp-admin — this still works because the files are still in both locations at this point.
2. Go to Settings > General.
3. Update both fields:

• WordPress Address (URL): https://yourdomain.com
• Site Address (URL): https://yourdomain.com

1. Click Save Changes.

Method B: Direct Database Edit (When Dashboard Is Inaccessible)

If the dashboard is already unreachable, use WP-CLI or phpMyAdmin:

# Using WP-CLI from the document root
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

Or in phpMyAdmin, run:

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

Replace wp_ with your actual table prefix if it was changed during installation.

Method C: Temporary wp-config.php Override

If both the dashboard and database are temporarily inaccessible, add these two lines to wp-config.php as a bootstrap override:

define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');

This overrides whatever is stored in the database. Remove these lines after confirming the dashboard is accessible and the database values have been updated permanently.

Step 3: Verify and Update the .htaccess File

The .htaccess file in the document root controls Apache's URL rewriting for WordPress. After moving files, this file should already be in public_html/ — but its RewriteBase directive must reflect the new root-level installation.

Open public_html/.htaccess and ensure it contains exactly the following WordPress rewrite block:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

The key change from a subdirectory installation is RewriteBase / instead of RewriteBase /wordpress/. If this line is wrong, all pretty permalinks return 404 errors while the homepage loads correctly — a classic diagnostic signature of a misconfigured RewriteBase.

Nginx users: WordPress does not use .htaccess. Update your server block's try_files directive instead:

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

Step 4: Flush Permalink Structure

WordPress caches the rewrite rules in the database. After changing the site URL, those cached rules reference the old path structure and must be regenerated.

1. Go to Settings > Permalinks in the WordPress dashboard.
2. Without modifying the selected permalink structure, click Save Changes.

This forces WordPress to rebuild and cache the rewrite rules against the new root-level path. Alternatively, use WP-CLI:

wp rewrite flush --hard

The --hard flag regenerates the .htaccess file in addition to flushing the database cache — useful if you are unsure whether the .htaccess is correct.

Step 5: Database-Wide URL Replacement

Moving files and updating siteurl/home is not sufficient. WordPress stores serialized URL strings throughout the database — in post content, postmeta, widget settings, theme options, and plugin configuration tables. Any remaining /wordpress path references will produce broken images, incorrect canonical tags, and malfunctioning plugin features.

Using Better Search Replace Plugin

1. Install and activate the Better Search Replace plugin.
2. Go to Tools > Better Search Replace.
3. Configure the replacement:

• Search for: https://yourdomain.com/wordpress
• Replace with: https://yourdomain.com

1. Select all database tables.
2. Uncheck Run as dry run? only after confirming the dry run shows the expected number of replacements.
3. Click Run Search/Replace.

Also run a second pass for the absolute server path:

• Search for: /public_html/wordpress
• Replace with: /public_html

Using WP-CLI (Preferred for Production)

WP-CLI's search-replace command handles serialized data correctly, which the naive SQL REPLACE() function does not:

wp search-replace 'https://yourdomain.com/wordpress' 'https://yourdomain.com' --all-tables --precise --report-changed-only

Run a second pass for absolute filesystem paths:

wp search-replace '/public_html/wordpress' '/public_html' --all-tables --precise --report-changed-only

The --precise flag uses PHP's serialization-aware replacement rather than regex, which prevents corrupting serialized arrays stored in the database.

Step 6: Implement 301 Redirects for SEO Continuity

If the site has been publicly accessible at /wordpress URLs — and especially if those URLs have been indexed by Google or linked from external sources — permanent redirects are mandatory, not optional. Without them, every indexed URL becomes a 404, and all accumulated link equity is lost.

Add the following redirect rule to public_html/.htaccess, above the WordPress rewrite block:

# Redirect legacy /wordpress/ URLs to root
RewriteEngine On
RewriteRule ^wordpress/(.*)$ /$1 [R=301,L]

This rule captures any request beginning with wordpress/ and redirects it to the equivalent root-level path. For example:

• yourdomain.com/wordpress/about/ → yourdomain.com/about/
• yourdomain.com/wordpress/wp-admin/ → yourdomain.com/wp-admin/

Important placement note: This redirect block must appear before the # BEGIN WordPress comment. WordPress's own rewrite rules will intercept the request first if the redirect is placed after them.

For Nginx, add this to the server block:

rewrite ^/wordpress/(.*)$ /$1 permanent;

Step 7: Post-Migration Validation

Systematic testing prevents silent failures from going undetected in production.

Functional Checks

Command-Line Validation

# Verify the homepage returns 200
curl -I https://yourdomain.com

# Verify the legacy URL issues a 301
curl -I https://yourdomain.com/wordpress/

# Check that wp-admin is reachable
curl -I https://yourdomain.com/wp-admin/

Google Search Console

Submit the updated sitemap in Google Search Console immediately after validation. Use the URL Inspection tool to request re-indexing of the homepage. Monitor the Coverage report over the following 48–72 hours for any spike in 404 errors, which would indicate missed URL replacements.

Step 8: Cleanup and Final Hardening

Once the site has been running stably at the root URL for 24–48 hours:

1. Delete the /wordpress subdirectory from the server. Leaving it in place creates a duplicate content risk and exposes a secondary entry point to the WordPress installation.

rm -rf /var/www/html/public_html/wordpress

1. Remove the WP_MAINTENANCE_MODE constant from wp-config.php if you added it.
2. Remove the temporary WP_HOME/WP_SITEURL defines from wp-config.php if you used Method C in Step 2.
3. Verify SSL coverage: If your SSL Certificate was issued for yourdomain.com/wordpress as a path-based scope (uncommon but possible in some configurations), confirm the certificate covers the apex domain correctly.
4. Update any external DNS or CDN configurations that may have cached the old path structure.
5. Purge all caching layers: Clear server-side page cache, object cache (Redis/Memcached), and CDN cache. Stale cache entries for /wordpress URLs will serve incorrect content even after the migration is complete.

Comparison: Migration Methods at a Glance

For any environment with SSH access — including Dedicated Servers and unmanaged VPS instances — the WP-CLI approach is the most reliable and least error-prone option.

Technical Decision Matrix

Use this matrix to determine which steps are mandatory versus situational for your specific scenario:

Key Takeaways

• The core operation is: copy files to document root, update siteurl and home in the database, fix .htaccess RewriteBase, run serialization-aware search-replace, add 301 redirects.
• Never use a plain SQL REPLACE() on WordPress tables without serialization handling — it will corrupt option values and break plugins silently.
• The .htaccess RewriteBase / directive is the single most commonly misconfigured element in this migration; a wrong value produces 404s on all permalink-based URLs while the homepage continues to load.
• 301 redirects are not cosmetic — they transfer link equity and prevent index fragmentation. They are mandatory for any site with existing search visibility.
• Delete the original /wordpress directory only after a 24-hour stable observation window.
• If you are running WordPress on a VPS with cPanel, use the File Manager's Show Hidden Files option to ensure .htaccess is included in the copy operation.

Frequently Asked Questions

Will removing /wordpress from the URL affect my SEO rankings?

Short-term, expect minor ranking fluctuations as Googlebot re-crawls the new URLs. If 301 redirects are correctly implemented, link equity transfers fully and rankings typically stabilize within two to four weeks. Skipping the 301 redirects causes permanent ranking loss for all previously indexed pages.

What if my WordPress dashboard is inaccessible after moving the files?

The most common cause is a mismatch between the siteurl value in the database and the actual file location. Use WP-CLI (wp option update siteurl) or add define('WP_SITEURL', 'https://yourdomain.com'); to wp-config.php as a temporary override to restore access.

Do I need to update wp-config.php after moving WordPress to the root?

In most cases, no. The wp-config.php file uses relative paths for the database connection and does not hard-code the installation path. The exception is if ABSPATH has been manually defined as an absolute path pointing to the old /wordpress directory — in that case, update or remove that line.

Why are images still broken after running Better Search Replace?

This usually means the plugin ran against a subset of tables and missed custom plugin tables or the wp_postmeta table. Re-run the replacement with all tables selected, and also check for absolute filesystem paths (e.g., /public_html/wordpress/wp-content/uploads/) in addition to the URL-based strings.

How do I handle this on a WordPress Multisite installation?

Multisite requires additional constants in wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) and the network's site URLs must be updated in both wp_site and wp_blogs tables. The standard single-site procedure is insufficient — treat this as a full network migration and test on a staging clone first.