If a WordPress site worked in MAMP but shows a 500 error, 404s on posts, or redirects to localhost:8888 after migration, fix it in this order: preserve the old server file, regenerate .htaccess from Settings > Permalinks, verify Apache rewrite support, correct both WordPress URL fields, remove any temporary RELOCATE setting, and then read the PHP or Apache log for the remaining error.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Do not start by repeatedly editing random rewrite lines. A MAMP installation and a live host can use different Apache settings, and a symptom such as a 500 response does not identify one cause. The procedure below separates WordPress configuration, Apache capability, leftover local URLs, and application errors so you can test each layer.
As an Amazon Associate I earn from qualifying purchases.
What changes when a MAMP site goes live
MAMP commonly serves a local site through an address such as http://localhost:8888. The live copy normally uses a domain and, often, HTTPS. WordPress stores those addresses in its settings and uses Apache rewrite rules to turn readable post and page paths into requests handled by WordPress.
After a move, three independent things can be wrong:
#1 Best Overall
- The server still has a local
.htaccess, or the file is malformed during the transfer. - The live Apache installation is not loading
mod_rewrite, or the virtual-host configuration does not allow directory-level overrides. - WordPress still believes its home is the MAMP URL, or that URL remains inside serialized database content.
The practical symptoms overlap. A front page can load while every post returns 404; a bad directive can produce a 500 Internal Server Error before WordPress runs; and an old URL can create redirects back to the computer that hosted MAMP. Treat each symptom as a clue, not a diagnosis.
Before changing the live site
Keep a reversible copy
Use your host’s file manager or SFTP to download the current server-side .htaccess. If it exists, rename it to something such as .htaccess_old rather than deleting it. The rename both disables the old rules and leaves a comparison copy if a later change needs to be reversed.
Recommended Free Tools
Also make a database backup before changing URL values. A database export gives you a recovery point if a search-and-replace operation touches more rows than intended. Keep a separate copy of wp-config.php, because temporary constants and database credentials are easy to alter accidentally.
Confirm where the live document root is
The .htaccess that controls WordPress must be in the live site’s document root, normally the directory containing wp-admin, wp-content, wp-includes, and index.php. A file left in a MAMP directory on your Mac cannot affect the hosted site.
Make hidden files visible
Names beginning with a dot are hidden in many file managers. Enable the option to show hidden files, or use an SFTP client that displays them, before concluding that the file is missing. Do not create a second file named .htaccess.txt; Apache will not treat that as .htaccess.
First fix: regenerate the WordPress rewrite rules
Regenerating is safer than hand-editing because WordPress writes the standard block for the site’s current permalink structure. It also provides a clean test of whether the web server permits WordPress to update the file.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Rank #2
- Used Book in Good Condition
- Log in to the live site’s WordPress administration area.
- Open Settings > Permalinks.
- Do not change the selected permalink option. Click Save Changes.
- WordPress will rewrite its managed block in the document-root
.htaccesswhen it can write the file. - If WordPress cannot write the file, the screen displays rewrite rules for you to copy. Paste those rules into the server’s
.htaccess, leaving unrelated host-specific rules in place unless you know they are obsolete.
After saving, test a post URL and a page URL, not just the home page. A successful home-page request can bypass the rewrite path entirely, while a post or page exercises the rules that were just generated.
What a normal WordPress block looks like
A conventional single-site installation uses a block similar to the following. The exact output from your own Permalinks screen takes precedence, especially when WordPress is installed in a subdirectory.
# 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 WordPressDo not paste this root-based example unchanged into a site installed below a path such as /blog. In that case, use the block WordPress prints for that installation. Keep any rules for redirects, security, caching, or a host control panel outside the managed WordPress markers so a later permalink save does not overwrite them.
Verify Apache, mod_rewrite, and override support
Confirm the server software
Pretty permalinks require Apache with mod_rewrite in the configuration described by the WordPress permalink guidance. A site running on IIS cannot use Apache’s mod_rewrite directives; it needs the rewrite mechanism appropriate to IIS instead. Ask the host which web server and rewrite module serve the domain if the control panel does not state this clearly.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Ask whether .htaccess overrides are allowed
Apache can be installed with rewrite support and still ignore a directory’s .htaccess because the virtual-host configuration disallows overrides. The relevant setting is commonly expressed through AllowOverride, but its value is controlled by the host and was not established by the WordPress administration screen. Request confirmation that the document root permits the rewrite directives used by WordPress.
Do not change a server-wide Apache configuration on shared hosting. Send the host the exact symptom, the document-root path, and the generated WordPress block, and ask whether AllowOverride and mod_rewrite are enabled for that directory. On a server you administer, make the configuration change in the virtual-host definition, reload Apache, and then repeat the permalink save.
Recognize an override failure
If saving Permalinks cannot create or update the file, or if a file that contains valid WordPress rules has no effect while the home page still loads, an override restriction is plausible. A 500 response immediately after adding a directive can instead mean that the host forbids that directive in .htaccess. The Apache error log distinguishes those cases; do not infer the setting from the browser’s generic error page.
Correct the two live-site URL settings
In the live dashboard, open Settings > General. Check both fields:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- WordPress Address (URL) — the URL where the WordPress core files are installed.
- Site Address (URL) — the public URL visitors use.
Both should use the live domain, include the intended scheme such as https://, and have no trailing slash. Neither field should contain localhost, localhost:8888, a MAMP port, or a local filesystem path. If WordPress is intentionally installed in a subdirectory, keep that subdirectory in the WordPress Address while using the public address in the Site Address as your deployment requires.
Save the fields, then open a private browser window and test the home page, one post, and one page. A cached redirect can make a corrected setting appear broken in your normal browser.
When the dashboard is inaccessible
You can temporarily define the values in wp-config.php:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Replace the example with the actual live values and omit a final slash. These constants override the corresponding wp_options values without changing what is stored in the database. That makes them useful for regaining access, but it also means the old database value will be used again if you later remove the constants. Keep a note of the temporary edit and remove or deliberately retain it only after deciding where the authoritative setting should live.
Do not put a local MAMP URL in one field and the live domain in the other unless the split is intentional and supported by your installation. A mismatch commonly produces redirect loops, missing assets, or login links that return to the old machine.
Remove temporary relocation settings
Some migrations use the RELOCATE constant while correcting a site’s address. It is a temporary relocation aid, not a permanent deployment setting. Leaving it in wp-config.php is insecure and can cause WordPress to derive a URL from the current request. Once the live URL fields or deliberate constants are correct, remove the RELOCATE line and test again.
Find MAMP URLs left in the database
Correcting the two URL fields does not rewrite every occurrence of the old address. MAMP URLs can remain in navigation settings, widget data, theme options, image references, or serialized values. Search the database for strings such as localhost:8888, the old local path, and the exact MAMP site URL.
Use a serialization-aware tool
A broad text replacement can corrupt serialized PHP data because serialized strings record their character length. Use a migration tool that understands serialization; WP-CLI’s wp search-replace is one example. Work on a backup or staging copy first, review the reported tables and replacements, and then repeat on the live database only when the result is understood. A typical operation conceptually replaces the complete old URL with the complete HTTPS domain, rather than replacing a fragment such as localhost that could match unrelated values.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsAfter the replacement, clear any object, page, or server cache and inspect several pages for images, menu links, forms, and canonical redirects. Search again for the old host name. Some records may legitimately retain a local value in an unrelated log or configuration table, so review matches before deleting them.
Diagnose a 500 Internal Server Error
A 500 response means the server could not complete the request; it does not prove that .htaccess is the cause. A corrupt or unsupported directive is widely cited as a common cause of WordPress 500 errors, but there is no published frequency figure that lets you assign a percentage to it.
Best Value
- Used Book in Good Condition
Turn on WordPress logging
When you can reach the dashboard, enable debugging in wp-config.php temporarily and log errors without displaying them to visitors:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reproduce the failing request, then inspect wp-content/debug.log. Check the host’s Apache or PHP error log as well; a parse error in .htaccess is reported by Apache and may never appear in the WordPress log.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Once the cause is identified, disable debugging on a public production site unless you have a controlled reason to keep logging enabled. Do not leave detailed errors displayed to visitors.
Isolate the file safely
- Rename the active file to
.htaccess_oldif you have not already done so. - Request the home page and record whether the 500 response disappears.
- If the error is gone, save Permalinks to generate a clean block.
- If the error remains with no
.htaccess, investigate PHP, a plugin, theme code, file permissions, or the host’s error log instead of continuing to edit rewrite rules.
Restore non-WordPress rules one group at a time. This identifies a conflicting redirect or security directive without mixing several changes into one test.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Manual editing: when it helps and when it hurts
Hand-writing the WordPress block is useful when the dashboard cannot write the file or when you need to preserve a carefully managed server configuration. It is error-prone because one unsupported directive, incorrect base path, or misplaced rule can create a 500 response or redirect loop.
| Approach | Best use | Main advantage | Main risk |
|---|---|---|---|
| Save Settings > Permalinks | Most normal migrations | WordPress generates rules for the current installation | Fails if the file is not writable or overrides are disabled |
| Paste the rules WordPress displays | Dashboard can read settings but cannot write the file | No need to guess the generated block | Incorrect placement or permissions can still prevent loading |
| Hand-write a block | Controlled server configuration or emergency recovery | Full control over file contents | Typos, wrong subdirectory paths, and unsupported directives |
Always retain the # BEGIN WordPress and # END WordPress markers around the managed section. Put custom redirects outside them, and keep a dated backup before each manual change.
Test the migration in a deliberate sequence
- Load the home page over the final HTTPS domain.
- Open one published post with a pretty permalink.
- Open one page, including a page nested below another page if your site uses that structure.
- Visit
/wp-admin/, sign in, and confirm that internal links remain on the live domain. - Check an image, a stylesheet, a navigation menu, a search result, and a form.
- Use a private window or cleared browser cache, then purge the WordPress and server caches.
- Review the Apache, PHP, and WordPress logs after the tests and turn off temporary debugging.
A post or page that returns 404 while the home page works points first to rewrite handling or a permalink flush. A redirect to MAMP points to URL configuration or stored content. A 500 response that disappears when .htaccess is renamed points toward a directive or override problem, while a persistent 500 requires application or server-log investigation.
Common failure patterns and the next action
| Symptom | Likely layer | Next action |
|---|---|---|
| Home page works; posts and pages are 404 | Rewrite rules, permalink state, or Apache rewrite support | Rename the old file, save Permalinks, and ask the host to confirm mod_rewrite and overrides. |
| Every request returns 500 after migration | Unsupported or malformed server directive, PHP error, or host configuration | Read Apache and PHP logs; isolate .htaccess by renaming it. |
| Visitors are sent to localhost or port 8888 | WordPress URL fields or database content | Correct both General Settings URLs, then run a serialization-aware search for the old address. |
| Dashboard cannot save the generated file | File ownership, permissions, or Apache override policy | Use the displayed rules manually and ask the host whether the document root permits overrides. |
| Corrected URLs return after removing constants | WP_HOME or WP_SITEURL was overriding stale database values |
Update the database-backed settings deliberately, then remove the constants only when the stored values are correct. |
What to tell your hosting provider
Support requests resolve faster when they contain reproducible details. Include the live domain, the document-root path, whether the home page works, one failing post URL, the exact time of the failure, and the relevant Apache or PHP log line. State that the site was moved from MAMP, that you renamed the old .htaccess, and whether saving Permalinks generated a new block. Ask specifically whether Apache, mod_rewrite, and AllowOverride are enabled for that directory. Do not send database credentials or the full wp-config.php in an unsecured ticket.
Quick Recap
Final recovery checklist
- The old server file is preserved as a backup, and the active file is in the live document root.
- Saving Settings > Permalinks generated or displayed a fresh block.
- The live host uses Apache with rewrite support, or you have configured the equivalent rewrite system for another server.
- Both WordPress URL fields use the live HTTPS domain with no trailing slash and no MAMP hostname or port.
- Any temporary
RELOCATEline has been removed. - Stored MAMP URLs have been reviewed and, where appropriate, replaced with a serialization-aware tool.
- The logs have been checked for the actual 500 cause.
- The home page, posts, pages, login, assets, forms, and redirects work after caches are cleared.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
