WordPress Help & Troubleshooting

1. Enable WP_DEBUG. Add define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); to wp-config.php. Check the debug log at wp-content/debug.log for the actual error.
2. Deactivate all plugins. Rename your wp-content/plugins folder to plugins.bak via File Manager or FTP. Reload — if the site comes back, a plugin is the cause. Rename back and reactivate one by one.
3. Switch to a default theme. Rename your active theme folder (e.g., mytheme → mytheme.bak). WordPress will fall back to the default theme.
4. Increase PHP memory. Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php. Low memory is a frequent WSOD cause.
5. Check PHP version. In cPanel, go to Select PHP Version and confirm your PHP version matches your theme/plugin requirements (typically PHP 8.0+).
6. Still blank? Open a support ticket with UnderHost. Include your PHP version, error log excerpts, and when the issue started.

Still need help? Contact UnderHost support →

1. Check the error log first. In cPanel → Error Logs or File Manager → error_log at your site root. The log usually points directly to the problem.
2. Repair or rename .htaccess. Rename .htaccess to .htaccess.bak. Reload. If the site loads, regenerate the file in WordPress → Settings → Permalinks → Save Changes.
3. Deactivate all plugins. A corrupted or incompatible plugin is the most common cause of a 500 error. Use File Manager to rename the plugins folder.
4. Check PHP memory. Add php_value memory_limit 256M to .htaccess or update php.ini if available in your hosting environment.
5. Check file permissions. Folders should be 755, files 644. Use File Manager or FTP to correct permissions on wp-content.
6. Contact support. If the server is returning a 500 with no clear log entry, the issue may be server-side. Open a ticket with UnderHost for investigation.

Still need help? Contact UnderHost support →

1. Check wp-config.php credentials. Open wp-config.php and verify DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST are correct. DB_HOST is usually localhost.
2. Test the database user in cPanel. In cPanel → MySQL Databases, confirm the user exists, has the correct password, and is assigned to the database.
3. Check if MySQL is running. If other sites on the same server are also down, the MySQL service may be down. Contact UnderHost support immediately.
4. Try the WordPress repair tool. Add define('WP_ALLOW_REPAIR', true); to wp-config.php, then visit yoursite.com/wp-admin/maint/repair.php. Remove the line after.
5. Check for a corrupted table. In cPanel → phpMyAdmin, select your database and run Repair Table on flagged tables. The wp_options table is a common culprit.
6. Contact UnderHost support if the database is inaccessible or phpMyAdmin cannot connect. This may be a server-level issue.

Still need help? Contact UnderHost support →

1. What causes it. When a WordPress update is interrupted (browser closed, timeout, network drop), a .maintenance file is left in the site root, keeping the site in maintenance mode indefinitely.
2. Delete the .maintenance file. In cPanel File Manager or via FTP, navigate to your site root (same folder as wp-config.php). Find the file named .maintenance and delete it. Enable "Show Hidden Files" if you don't see it.
3. Reload your site. The maintenance message should be gone immediately after deleting the file.
4. Check for interrupted updates. Go to Dashboard → Updates and re-run any pending plugin, theme, or core updates one at a time.
5. Prevent future issues. Avoid navigating away or closing your browser during updates. On slow connections, updates can time out — consider using WP-CLI for large updates.

Still need help? Contact UnderHost support →

1. Clear your browser cache and cookies first. Old cached redirects in the browser are often the cause. Press Ctrl+Shift+Delete and clear everything, then retry.
2. Check WordPress and Site Address URLs. In Settings → General, both WordPress Address (URL) and Site Address (URL) must use the same protocol (http or https) and www/non-www format.
3. Fix via wp-config.php if locked out. Add these two lines before /* That's all */: define('WP_HOME', 'https://yourdomain.com'); and define('WP_SITEURL', 'https://yourdomain.com');
4. Check .htaccess for conflicting redirect rules. Rename .htaccess to .htaccess.bak and test. If the loop stops, a bad redirect rule in that file is the cause.
5. Check Cloudflare SSL mode. If using Cloudflare, set the SSL mode to Full (Strict) in Cloudflare → SSL/TLS. "Flexible" mode causes redirect loops when WordPress is already forcing HTTPS.
6. Deactivate all plugins. A redirection or SEO plugin with a bad rule is a common cause. Deactivate all, test, then reactivate one by one.

Still need help? Contact UnderHost support →

1. Clear browser cookies for your domain. The most common cause is a stale or corrupt WordPress auth cookie. Clear cookies, close and reopen the browser, then try logging in.
2. Check WordPress Address vs Site Address. In wp-config.php or Settings → General, confirm both URLs are identical — same protocol, same www or non-www. A mismatch breaks cookie domain matching.
3. Rename .htaccess in wp-admin. An .htaccess file inside the wp-admin/ folder can block the login session. Via FTP or File Manager, rename wp-admin/.htaccess to .htaccess.bak and test.
4. Deactivate plugins via FTP. A caching or security plugin is often the culprit. Rename wp-content/plugins to plugins.bak, try logging in, then rename back.
5. Check for a caching plugin caching the login page. Login pages should always be excluded from cache. Verify your caching plugin excludes /wp-login.php and /wp-admin/.
6. Contact UnderHost support if the above steps don't resolve it. Session handling at the server level (e.g., PHP session save path misconfigured) can also cause this.

Still need help? Contact UnderHost support →

1. What causes mixed content. After moving to HTTPS, images, scripts, or stylesheets still loading over HTTP trigger mixed content warnings in browsers, breaking the padlock and sometimes blocking page functionality.
2. Install Really Simple SSL or Better Search Replace. Really Simple SSL auto-fixes mixed content on the fly. Better Search Replace lets you run a database search-and-replace to update all http://yourdomain.com references to https://yourdomain.com.
3. Manual database fix via phpMyAdmin. Use the SQL query: UPDATE wp_options SET option_value = REPLACE(option_value, 'http://yourdomain.com', 'https://yourdomain.com'); Run similar queries on wp_posts and wp_postmeta.
4. Add to wp-config.php. Add define('FORCE_SSL_ADMIN', true); to force the admin area over HTTPS.
5. Check hardcoded URLs in theme files. Some themes hardcode http:// URLs in templates. Search your theme files for http:// and update to https:// or use // (protocol-relative) URLs.
6. Use browser DevTools. In Chrome, open DevTools → Console. Mixed content errors show exactly which resources are being loaded insecurely.

Still need help? Contact UnderHost support →

1. Why scheduled posts fail. WordPress relies on WP-Cron to publish scheduled posts. WP-Cron is triggered by site visits — if no one visits your site near the scheduled time, or if WP-Cron is disabled, posts stay in "Scheduled" status indefinitely.
2. Check if WP-Cron is disabled. Open wp-config.php and search for DISABLE_WP_CRON. If it's set to true, WP-Cron is off and scheduled tasks won't fire automatically.
3. Set up a real server cron job. In cPanel → Cron Jobs, add: wget -q -O - "https://yourdomain.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1 — set it to run every 5 or 15 minutes. This is more reliable than the default WP-Cron trigger.
4. Use the WP Crontrol plugin. Install WP Crontrol (free) to see all scheduled events, check when they're due to run, and manually trigger them. It immediately shows if events are stuck.
5. Check your server timezone. A mismatch between your WordPress timezone (Settings → General → Timezone) and the server timezone causes posts to publish at unexpected times or not at all.
6. Publish missed posts manually. If posts are already stuck as "Scheduled", edit each one and click Update/Publish. Going forward, the cron fix above prevents recurrence.
7. Contact UnderHost support if outbound requests from the server to wp-cron.php are being blocked. We can verify and whitelist the cron endpoint.

Still need help? Contact UnderHost support →

1. Install Akismet Anti-Spam. Akismet is included with WordPress and is the most effective comment spam filter available. Activate it and connect a free Akismet API key (free for personal sites at akismet.com).
2. Require moderation for all new commenters. In Settings → Discussion, enable "Comment must be manually approved" or "Comment author must have a previously approved comment". This stops all spam from appearing publicly.
3. Add a CAPTCHA to comments. Install the WPBruiser or hCaptcha for WordPress plugin to add a challenge to the comment form. Most spam bots can't solve CAPTCHAs.
4. Disable comments on old posts. In Settings → Discussion, enable "Automatically close comments on posts older than X days". Spam bots disproportionately target old posts.
5. Disable comments site-wide if not needed. If your site doesn't need comments at all, go to Settings → Discussion and uncheck "Allow people to submit comments on new posts". For existing posts, you can bulk-close comments in Posts → All Posts.
6. Block comment spam via .htaccess. You can block known spam referrers or require a valid referer header. Many spam bots post directly to wp-comments-post.php without loading the page — add a referer check to block these.
7. Clean up existing spam. In Comments → spam, select all and click "Delete Permanently". Run this regularly or use WP-Optimize to automate it.

Still need help? Contact UnderHost support →

1. Enable debugging to find the error. Add to wp-config.php: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); Then check wp-content/debug.log.
2. Parse errors from recent edits. If the error appeared after editing a PHP file (theme functions.php, etc.), a syntax mistake (missing semicolon, unmatched bracket) is the cause. Restore the file from backup or fix via FTP.
3. Fatal errors from plugin/theme updates. If the error appeared after an update, deactivate that plugin/theme via FTP by renaming its folder. Then contact the plugin author or restore the previous version.
4. Check PHP version compatibility. In cPanel → MultiPHP Manager, verify your PHP version matches your theme and plugin requirements. PHP 8.x introduced strict type handling that breaks plugins written for PHP 7.x.
5. Recovery Mode (WordPress 5.2+). WordPress emails you a special recovery mode link when a fatal error occurs. Check the admin email for a "Your Site is Experiencing a Technical Difficulty" message with a recovery URL.
6. Restore from backup if you cannot identify the broken file. Contact UnderHost for assistance accessing a clean server-side backup.

Still need help? Contact UnderHost support →

1. Switch to a default theme first. Go to Appearance → Themes and activate Twenty Twenty-Four (or any bundled default theme). If the issue disappears, your theme is the cause.
2. Deactivate all plugins. In Plugins → Installed Plugins, select all and choose Deactivate. Reload your site. If it works, a plugin is the cause.
3. Reactivate plugins one by one. Activate each plugin, reload the site, and test. The plugin that breaks the site is the conflict.
4. Cannot access wp-admin? Use File Manager or FTP to rename wp-content/plugins to plugins.bak. Log in, then rename back and identify via the admin.
5. Check for plugin updates. Outdated plugins are a major source of conflicts. Always keep plugins and themes updated.
6. Use a staging environment to test plugin updates before applying them to your live site. Ask UnderHost support if you need staging help.

Still need help? Contact UnderHost support →

1. Disable all plugins via FTP/File Manager: Navigate to wp-content/ and rename the plugins folder to plugins_disabled. WordPress will deactivate all plugins.
2. Re-enable plugins: Rename the folder back to plugins. WordPress will show all plugins as deactivated — re-enable them individually from wp-admin.
3. Disable a single plugin: Navigate to wp-content/plugins/ and rename the specific plugin folder (e.g., jetpack → jetpack_off).
4. Via phpMyAdmin: In your wp_options table, find the row where option_name = 'active_plugins'. Set option_value to a:0:{} to deactivate all plugins.
5. Re-enable from phpMyAdmin: After logging into wp-admin, go to Plugins and re-enable what you need.

Still need help? Contact UnderHost support →

1. Always backup before updating. Use UpdraftPlus or cPanel Backup to take a full site + database snapshot before any updates. This takes 2–5 minutes and can save hours of recovery work.
2. Update one at a time. Avoid bulk-updating all plugins simultaneously. Update one, test the site, then move to the next. This isolates which update caused a problem.
3. Update plugins before WordPress core. Plugin/theme authors often release compatibility updates ahead of a major WordPress release. Update plugins first, then update core.
4. Read changelogs before major version updates. On the plugin page, click "View version X.X details" to see what changed. Breaking changes, deprecated features, or new requirements may affect your site.
5. Use a staging environment for major updates. For e-commerce sites, membership sites, or any revenue-critical WordPress site, test all updates on staging before applying to production. Ask UnderHost about staging options.
6. After updating: Test all key pages — homepage, checkout, forms, login, and any custom functionality. Clear all caches after the update.

Still need help? Contact UnderHost support →

1. When to install manually. Use this method when the built-in installer fails due to file size limits, timeout, or FTP credential errors in the admin.
2. Download the theme/plugin ZIP. From the developer's site or wordpress.org, download the ZIP file to your computer. Do not unzip it yet — or unzip it and upload the folder directly.
3. Connect via FTP or File Manager. Use your FTP client (FileZilla, etc.) or cPanel File Manager to connect to your server.
4. Navigate to the correct directory. For plugins: wp-content/plugins/. For themes: wp-content/themes/.
5. Upload the folder. Unzip the ZIP locally and drag the plugin/theme folder into the correct directory, or use File Manager's Upload & Extract feature to upload the ZIP directly.
6. Activate from wp-admin. Go to Plugins → Installed Plugins (or Appearance → Themes) and activate the newly uploaded item.
7. Set correct permissions. Plugin and theme folders should be 755, files 644. Incorrect permissions cause "could not create directory" or activation errors.

Still need help? Contact UnderHost support →

1. Check if auto-updates are disabled in wp-config.php. Search for AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE. If set to false, auto-updates are disabled globally.
2. Check file permissions. WordPress needs write permission to its own files to update. Folders should be 755 and files 644. If WordPress can't write files, updates will silently fail.
3. Check wp-cron. Auto-updates rely on WP-Cron. If define('DISABLE_WP_CRON', true); is set in wp-config.php and no real server cron is configured as a replacement, scheduled tasks won't run.
4. Check for a security plugin blocking updates. Some WAF or hardening plugins block outbound update requests. Check Wordfence, iThemes Security, or similar plugins for firewall or update blocking rules.
5. Re-enable minor auto-updates. To allow automatic minor (security) updates only, add to wp-config.php: define('WP_AUTO_UPDATE_CORE', 'minor');
6. Contact UnderHost support if the server firewall is blocking outbound connections to wordpress.org update servers. This is a server-level fix.

Still need help? Contact UnderHost support →

1. What the HTTP error means. The vague "HTTP error" popup in the media uploader is WordPress's catch-all for a server-side failure during upload. It does not necessarily mean the image itself is broken.
2. Try renaming the file. Remove any special characters, spaces, or accented letters from the filename before uploading. Rename to something like hero-image.jpg. This alone fixes the error in many cases.
3. Reduce the image file size. Large images (10MB+) can hit memory limits during processing. Compress the image to under 2MB with TinyPNG or Squoosh before uploading.
4. Increase PHP memory limit. Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php. Insufficient memory during image resizing causes the HTTP error.
5. Disable ImageMagick and switch to GD Library. Add to wp-config.php: define('WP_IMAGE_EDITOR_CLASS', 'WP_Image_Editor_GD'); A misconfigured ImageMagick installation is a frequent HTTP error cause on shared hosting.
6. Check and repair .htaccess. Rename .htaccess to .htaccess.bak and try uploading again. A corrupted rewrite rule can interfere with the upload handler.
7. Deactivate all plugins. Security plugins (especially those that apply custom file filters) can block uploads. Deactivate all plugins, test, then reactivate one by one to find the culprit.
8. Contact UnderHost support if the issue persists. We can check server error logs for the precise PHP error and adjust server-level image processing settings.

Still need help? Contact UnderHost support →

1. Check your current limit. Go to Media → Add New in your WordPress admin. The current maximum upload size is shown at the bottom of the upload area.
2. Method 1 — .htaccess (Apache): Add these lines to your .htaccess file: php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300
3. Method 2 — php.ini: If your host allows a custom php.ini in the site root, create or edit it and add: upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
4. Method 3 — cPanel MultiPHP INI Editor: In cPanel → MultiPHP INI Editor, select your domain, find upload_max_filesize and post_max_size, and increase both.
5. Important: post_max_size must be larger than upload_max_filesize. If post_max_size is smaller, the upload will fail regardless of the file size limit.
6. Verify the change. Go to Tools → Site Health → Info → Server and check the "Upload max file size" row. It should reflect your new value.
7. Contact UnderHost support if none of the above methods work. Some server configurations have a hard cap that only an administrator can raise.

Still need help? Contact UnderHost support →

1. What this error means. WordPress was able to receive the file but could not write it to the wp-content/uploads/ directory. This is almost always a file permissions or disk space problem.
2. Fix folder permissions. The wp-content/uploads/ directory must be writable by the web server. Set it to 755 via cPanel File Manager → right-click → Change Permissions. If 755 doesn't work, try 775 — but never use 777.
3. Check disk space. In cPanel → Disk Usage, verify your hosting account has available disk space. If you're at or near your quota, the server cannot write new files.
4. Create the uploads directory if missing. Navigate to wp-content/ in File Manager. If the uploads folder doesn't exist, create it and set permissions to 755.
5. Check the uploads subfolder structure. WordPress creates year/month subfolders (e.g., uploads/2026/05/). If the web server user can't create subfolders, uploading fails. Setting the uploads root to 755 and owner to the correct user fixes this.
6. Check owner/group via SSH. Run ls -la wp-content/uploads/. The directory owner should match your web server user (typically nobody or your cPanel username). Contact UnderHost support to correct file ownership if needed.
7. Disable any security plugin that restricts writes. Some hardening plugins prevent PHP from writing files as a security measure. Temporarily deactivate all security plugins and test.

Still need help? Contact UnderHost support →

1. Why images break during migration. Image paths in the WordPress database contain the full URL of the old site. After migration to a new domain or server, the paths still point to the old location and return 404s.
2. Run a search and replace on the database. Use the Better Search Replace plugin: install it, enter your old URL in the Search field and new URL in Replace, select all tables, and run. This fixes all stored image paths at once.
3. Or use WP-CLI: wp search-replace "https://oldsite.com" "https://newsite.com" --all-tables
4. Check if the files were actually copied. Browse to wp-content/uploads/ in File Manager. If the images physically aren't there, you need to re-upload or transfer them from the old server via FTP.
5. Verify the uploads base URL setting. In Settings → Media, check the "Uploading Files" section. The upload path should be blank (default) or a correct relative path. An old absolute path here will break all uploads.
6. Regenerate thumbnails. Even after fixing URLs, thumbnails generated at the old server's image dimensions may be missing. Install and run the Regenerate Thumbnails plugin to recreate all thumbnail sizes for the new server.
7. Check .htaccess for old domain redirects. If the old site's .htaccess was copied over, it may contain redirect rules pointing back to the old domain. Review and clean up any old redirect rules.

Still need help? Contact UnderHost support →

1. Clear browser cache and cookies first. Press Ctrl+Shift+Delete and clear cache and cookies for your domain. Media Library uses JavaScript heavily — cached broken scripts are a common cause.
2. Deactivate all plugins and test. A plugin conflict is the most common cause of a broken Media Library. Rename the plugins folder via FTP to deactivate all, then test. Reactivate one by one to find the conflict.
3. Switch to a default theme. Theme functions.php that enqueue scripts or add custom admin styles can interfere with the Media Library. Test with Twenty Twenty-Four.
4. Check for JavaScript errors. Open your browser DevTools (F12) → Console tab while the Media Library is open. JavaScript errors will point to the specific plugin or script causing the problem.
5. Increase PHP memory. The Media Library loads all attachment data for display. On large media libraries, low PHP memory causes the page to silently fail. Increase to 256M in wp-config.php.
6. Check user capabilities. Ensure your user account has the upload_files capability. In rare cases, a plugin can strip capabilities from existing users. Confirm via Users → your profile that your role is Administrator.
7. Reset .htaccess. Rename .htaccess to .htaccess.bak and go to Settings → Permalinks → Save Changes to regenerate it. A corrupted .htaccess can block the AJAX calls the Media Library depends on.

Still need help? Contact UnderHost support →

1. Method 1 — Email reset: Go to yoursite.com/wp-login.php → Lost your password? Enter your username or admin email address and submit.
2. Method 2 — phpMyAdmin: In cPanel, open phpMyAdmin. Select your WordPress database → wp_users table → find your user → click Edit. Set user_pass to a new MD5-hashed password (use a tool like md5hashgenerator.com). Save.
3. Method 3 — WP-CLI (if available): Run wp user update 1 --user_pass="NewPassword123" from SSH to reset the admin password instantly.
4. Contact UnderHost support if you have no access to email, phpMyAdmin, or cPanel. We can assist with identity-verified account recovery.

Still need help? Contact UnderHost support →

1. When to use this. Use this method when you're completely locked out of wp-admin and cannot reset the password via email.
2. Open phpMyAdmin. In cPanel → Databases → phpMyAdmin. Select your WordPress database from the left sidebar.
3. Insert into wp_users. Click the wp_users table → Insert tab. Fill in: user_login (username), user_pass (select MD5 from the function dropdown and type your password), user_email, user_registered (current datetime), user_status = 0, display_name. Click Go.
4. Note the new user ID. After inserting, find the new row and note the ID value (e.g., 3).
5. Insert into wp_usermeta. Click wp_usermeta → Insert. Add two rows: (1) user_id = your new ID, meta_key = wp_capabilities, meta_value = a:1:{s:13:"administrator";b:1;}. (2) user_id = your ID, meta_key = wp_user_level, meta_value = 10.
6. Log in. Go to yoursite.com/wp-login.php and log in with your new username and password.

Still need help? Contact UnderHost support →

1. Update admin email via phpMyAdmin. In cPanel → phpMyAdmin, open your WordPress database → wp_options table. Find the row where option_name = 'admin_email' and update option_value to an email you can access.
2. Update the user email in wp_users. Also update user_email in the wp_users table for the admin account to match the new email.
3. Request a password reset. Now go to wp-login.php → Lost your password? and use the updated email address to receive the reset link.
4. Via WP-CLI (SSH): wp user update 1 --user_email="newemail@domain.com" then wp user reset-password 1
5. Contact UnderHost support with proof of domain ownership if you need identity-verified admin recovery assistance.

Still need help? Contact UnderHost support →

1. Disable wp-cron and switch to a real cron job. In wp-config.php, add define('DISABLE_WP_CRON', true);. Then set up a real cron in cPanel → Cron Jobs: wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron every 15 minutes. Frequent wp-cron calls during page loads slow the admin.
2. Disable the Heartbeat API or reduce its frequency. The WordPress Heartbeat makes AJAX calls every 15 seconds in the editor, adding server load. Use the Heartbeat Control plugin to reduce or disable it on the dashboard.
3. Check for slow admin-ajax.php calls. Use Query Monitor plugin to identify slow queries or plugins generating excessive AJAX calls in the background.
4. Deactivate resource-heavy plugins. Security plugins that scan on every page load, excessive analytics plugins, or broken plugins making external API calls can slow the entire dashboard.
5. Increase PHP max_execution_time. In cPanel → MultiPHP INI Editor, increase max_execution_time to 120–300 seconds for your domain to prevent timeout on complex admin tasks.
6. Consider upgrading hosting. If your shared hosting CPU is consistently maxed, dashboard slowness is a resource limit issue. Ask UnderHost about VPS or managed WordPress hosting.

Still need help? Contact UnderHost support →

1. Via wp-config.php (recommended): Add define('WP_MEMORY_LIMIT', '256M'); before /* That's all, stop editing! */.
2. Via .htaccess: Add php_value memory_limit 256M to the top of your .htaccess file.
3. Via php.ini: If your host allows a custom php.ini, add memory_limit = 256M.
4. In cPanel → MultiPHP INI Editor: Select your domain, find memory_limit and increase it.
5. Verify the change: Install Health Check & Troubleshooting plugin or create a file with and check the memory_limit value.
6. Note: If your hosting plan has a hard memory cap, you may need to upgrade your plan. Contact UnderHost support for assistance.

Still need help? Contact UnderHost support →

1. Regenerate .htaccess: In WordPress admin, go to Settings → Permalinks → click Save Changes (no changes needed). This regenerates the .htaccess file.
2. Check mod_rewrite is enabled: Your server needs Apache mod_rewrite. If you're on nginx, you need specific rewrite rules. Contact UnderHost support for nginx configuration.
3. Check .htaccess contents: The file should contain WordPress rewrite rules. If it's missing or incorrect, paste the standard WordPress .htaccess block from wordpress.org/support.
4. Verify .htaccess permissions: The file should be readable by Apache. Set permissions to 644.
5. Still broken? In some shared hosting setups, AllowOverride must be set to All in the Apache config. Contact UnderHost if you've confirmed the above steps and still have 404s on posts.

Still need help? Contact UnderHost support →

1. Install Query Monitor or WP Hive: Identify slow database queries, PHP errors, and heavy plugins.
2. Check for an overloaded shared server: If speed varies throughout the day, your shared server may be resource-constrained. Consider upgrading to a VPS. Ask UnderHost about VPS options.
3. Enable a caching plugin: W3 Total Cache, WP Super Cache, or LiteSpeed Cache (if on a LiteSpeed server). Caching is the single biggest performance improvement for most WordPress sites.
4. Optimise images: Use WebP images and a plugin like Imagify, ShortPixel, or EWWW Image Optimizer.
5. Use a CDN: Offload static assets (CSS, JS, images) through Cloudflare or the UnderHost CDN add-on.
6. Limit WordPress revisions: Add define('WP_POST_REVISIONS', 5); to wp-config.php to stop database bloat from unlimited revisions.
7. Clean the database: Use WP-Optimize or Advanced Database Cleaner to remove old revisions, spam comments, transients, and post meta.

Still need help? Contact UnderHost support →

1. LiteSpeed Cache: Install the LiteSpeed Cache plugin (free). It works natively with LiteSpeed Web Server — available on UnderHost LiteSpeed plans. Enable Page Cache, Image Optimization, and CDN settings.
2. Object cache / Redis: If your UnderHost plan includes Redis, enable it via cPanel → Redis. Then add to wp-config.php: define('WP_REDIS_HOST', '127.0.0.1'); and install the WP Redis plugin.
3. Memcached: Some plans offer Memcached instead of Redis. Install the W3 Total Cache plugin and select Memcached as the object cache backend.
4. OPcache: PHP OPcache is usually enabled by default on UnderHost plans. Verify in cPanel → MultiPHP INI Editor → check opcache settings.
5. Ask UnderHost support if you're unsure which cache technologies your plan supports. We can confirm what's available and help with configuration.

Still need help? Contact UnderHost support →

1. From your caching plugin: Most caching plugins have a "Clear Cache" button in the WordPress admin toolbar. Click it after making changes.
2. LiteSpeed Cache: In WordPress admin, click LiteSpeed → Purge → Purge All, or use the top admin bar shortcut.
3. W3 Total Cache: Performance → Purge All Caches.
4. WP Super Cache: Settings → WP Super Cache → Delete Cache.
5. Cloudflare: If using Cloudflare, log in to your dashboard → Caching → Configuration → Purge Everything.
6. cPanel/Server-level: In cPanel, look for "Cache Manager" or contact UnderHost support to flush OPcache or server-level caches.
7. Browser cache: Press Ctrl+Shift+R (or Cmd+Shift+R on Mac) to hard-reload and bypass your local browser cache.

Still need help? Contact UnderHost support →

1. Convert images to WebP. WebP images are 25–35% smaller than JPEG/PNG with equivalent quality. Use Imagify, ShortPixel, or EWWW Image Optimizer plugins to auto-convert and serve WebP to supported browsers.
2. Enable lazy loading. WordPress enables native lazy loading by default (adding loading="lazy" to images). Verify it's not being disabled by your theme or a page builder. Lazy loading defers off-screen images until the user scrolls near them.
3. Compress images before uploading. Aim for images under 150KB for content images, under 500KB for hero/banner images. Use tools like TinyPNG, Squoosh, or your image optimizer plugin's bulk compression feature.
4. Set correct image dimensions. Upload images at the exact display size. Avoid uploading a 4000px wide image to display in a 600px column — this wastes bandwidth and slows the page.
5. Use a CDN for images. Offload image delivery to Cloudflare or a CDN add-on so images load from a server geographically close to each visitor.
6. Clean up media library. Use the Media Cleaner plugin to find and remove unused images that are taking up disk space and database entries.

Still need help? Contact UnderHost support →

1. What are Core Web Vitals. Google measures three key metrics: LCP (Largest Contentful Paint — how fast main content loads), INP (Interaction to Next Paint — responsiveness), and CLS (Cumulative Layout Shift — visual stability). These directly affect SEO.
2. Improve LCP. Preload your hero image by adding <link rel="preload" as="image" href="hero.jpg"> to your theme's <head>. Serve images via CDN. Avoid render-blocking resources above the fold. Use a fast hosting plan.
3. Improve INP (was FID). Defer or remove unused JavaScript. Break up long-running scripts. Remove or replace heavy page builders that inject large JS bundles. Use WP Rocket or Flying Scripts to delay non-critical JS.
4. Fix CLS. Always set explicit width and height attributes on images and videos so the browser reserves space before they load. Avoid injecting content above existing content (banners, cookie notices).
5. Eliminate render-blocking resources. Use WP Rocket, NitroPack, or LiteSpeed Cache to defer non-critical CSS/JS. Inline critical CSS and load the rest asynchronously.
6. Test with PageSpeed Insights. Visit pagespeed.web.dev, enter your URL, and follow the specific recommendations for your site. Aim for 80+ mobile / 90+ desktop, but prioritize Core Web Vitals passing status.

Still need help? Contact UnderHost support →

1. Limit post revisions. Add define('WP_POST_REVISIONS', 5); to wp-config.php. WordPress stores unlimited revisions by default, causing database bloat over time.
2. Use WP-Optimize or Advanced Database Cleaner. These plugins let you safely remove: old post revisions, auto-draft posts, trashed posts, spam and trashed comments, expired transients, and orphaned plugin metadata.
3. Optimize database tables. In phpMyAdmin, select all tables and run Optimize Table from the dropdown. This reclaims space from deleted rows and defragments indexes. WP-Optimize can do this automatically.
4. Clean up transients. Plugins often store temporary data (transients) in wp_options. Expired transients accumulate over time and slow queries on the options table.
5. Schedule regular cleanups. WP-Optimize and Advanced Database Cleaner can schedule automatic weekly or monthly cleanups. Set these up and forget them.
6. Consider a database index review. On large sites (10,000+ posts), missing indexes on wp_postmeta or wp_options cause slow queries. Contact UnderHost support for database-level optimization on high-traffic sites.

Still need help? Contact UnderHost support →

1. Use a performance plugin. WP Rocket, LiteSpeed Cache, NitroPack, or Autoptimize handle minification, combination, and deferral of CSS/JS with minimal configuration.
2. Minify CSS. Minification strips whitespace, comments, and unnecessary characters from CSS files, reducing file size by 10–30%. Enable in your caching/performance plugin settings.
3. Minify and defer JavaScript. Combine JS files where possible and add defer or async attributes to non-critical scripts. Deferred scripts load after the page HTML renders, eliminating render-blocking.
4. Inline critical CSS. Extract the CSS needed to render above-the-fold content and inline it directly in <head>. Load the full stylesheet asynchronously. WP Rocket and NitroPack automate this.
5. Remove unused CSS. Page builders and themes load CSS for every block type, even ones not used on a given page. Perfmatters or Asset CleanUp let you disable specific scripts/styles per page.
6. Test before and after. Use GTmetrix or PageSpeed Insights to measure before enabling optimizations. Test all pages after — aggressive JS deferral can break sliders, forms, or checkout flows if not configured carefully.

Still need help? Contact UnderHost support →

1. Keep everything updated. WordPress core, all plugins, and all themes should always be on the latest stable version.
2. Use strong, unique passwords. Use a password manager. Never reuse your WordPress admin password anywhere else.
3. Enable two-factor authentication (2FA). Install the WP 2FA or Google Authenticator plugin on the admin account.
4. Limit login attempts. Install Limit Login Attempts Reloaded or use Wordfence to block brute-force attacks.
5. Change the default login URL. Use WPS Hide Login to move wp-admin to a custom URL. This reduces automated attack traffic significantly.
6. Remove the admin username. Create a new admin user with a non-obvious username, log in as that user, then delete the "admin" account.
7. Disable file editing from wp-admin. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php.
8. Set correct file permissions. wp-config.php should be 600 or 640. Folders 755, files 644.
9. Install a security plugin. Wordfence, Sucuri Security, or iThemes Security for active monitoring and firewall rules.
10. Enable UnderHost's server-side protection where available — ask support about WAF, malware scanning, and hardening add-ons.

Still need help? Contact UnderHost support →

1. Do not panic — act methodically. Take a backup of the current (possibly infected) state before doing anything, so you can reference files.
2. Put the site in maintenance mode to prevent further damage and protect visitors from malicious redirects or code.
3. Change all passwords immediately: WordPress admin, cPanel/FTP, database password, and your email account.
4. Run a malware scan: Use Wordfence Free Scan, Sucuri SiteCheck, or ask UnderHost to run a server-side malware scan.
5. Restore from a clean backup if available. This is the fastest and most reliable recovery method. Contact UnderHost about backup restoration.
6. Identify the infection point: Check access logs for suspicious POST requests, new files with recent timestamps, and encoded/obfuscated PHP.
7. Common malware locations: wp-content/uploads/ (PHP files should not exist here), wp-includes/, functions.php injected code.
8. After cleanup: Update everything, replace WordPress core files from a fresh download, apply security hardening steps, and enable monitoring.
9. Contact UnderHost support for managed malware cleanup. We offer professional remediation services.

Still need help? Contact UnderHost support →

1. What is XML-RPC. XML-RPC is a remote publishing protocol WordPress includes by default. Attackers exploit it for brute-force attacks (one request can attempt thousands of passwords) and DDoS amplification.
2. Disable via .htaccess (Apache). Add to your .htaccess: <Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
3. Disable via a plugin. Install "Disable XML-RPC" (by John Blackbourn) — it's a single-purpose, lightweight plugin that disables all XML-RPC access with no configuration.
4. Or disable selectively. If you use Jetpack (which needs XML-RPC), add to functions.php: add_filter('xmlrpc_methods', function($m){ unset($m['system.multicall']); return $m; }); — this blocks the method most abused in brute-force attacks.
5. Check if it's already being hit. Search your access logs for xmlrpc.php POST requests. Hundreds or thousands of hits per day is normal for a targeted site — blocking XML-RPC will immediately reduce server load.

Still need help? Contact UnderHost support →

1. Install an SSL certificate first. In cPanel → SSL/TLS or AutoSSL, install a free Let's Encrypt certificate for your domain. UnderHost provides free AutoSSL on all hosting plans.
2. Update WordPress URLs to HTTPS. In Settings → General, change both WordPress Address and Site Address from http:// to https://.
3. Force HTTPS in .htaccess. Add above the WordPress rules: RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
4. Fix mixed content. Use the Really Simple SSL plugin to automatically fix internal links and resources still loading over HTTP. Or use Better Search Replace to update all http://yourdomain.com to https://yourdomain.com in the database.
5. Add to wp-config.php. Add define('FORCE_SSL_ADMIN', true); to keep the admin area always on HTTPS.
6. Test your SSL. Visit SSL Labs (ssllabs.com/ssltest/) or Why No Padlock? to verify your certificate and check for mixed content issues.

Still need help? Contact UnderHost support →

1. Install a login protection plugin. Wordfence, Limit Login Attempts Reloaded, or WP Cerber block IP addresses after a configurable number of failed login attempts.
2. Enable two-factor authentication (2FA). Use WP 2FA, Google Authenticator, or Wordfence 2FA. Even if an attacker guesses your password, 2FA stops them from logging in.
3. Rename the login URL. Use WPS Hide Login to change /wp-login.php to a custom URL like /mysecretlogin. This alone blocks the vast majority of automated attacks that only target the default URL.
4. Block via .htaccess (IP allowlist). If only a few known IPs should access wp-admin, add to wp-admin/.htaccess: Order Deny,Allow
Deny from all
Allow from YOUR.IP.HERE
5. Disable XML-RPC. Brute-force attackers often use xmlrpc.php instead of wp-login.php to bypass per-attempt limits. See the separate XML-RPC article to disable it.
6. Use Cloudflare Bot Fight Mode. If your site is behind Cloudflare, enable Bot Fight Mode and consider creating a WAF rule to challenge or block requests to /wp-login.php that don't match your country or IP.

Still need help? Contact UnderHost support →

1. Correct permission values. Directories: 755. Files: 644. wp-config.php: 600 (read/write by owner only). .htaccess: 644.
2. Set permissions via File Manager. In cPanel File Manager, right-click a folder → Change Permissions. To set recursively, select all files/folders and change permissions.
3. Set permissions via SSH/WP-CLI. From SSH: find /path/to/wordpress -type d -exec chmod 755 {} \; and find /path/to/wordpress -type f -exec chmod 644 {} \;
4. Protect wp-config.php. This file contains your database credentials. Set it to 600: chmod 600 wp-config.php. Also add to .htaccess: <Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>
5. Disable PHP execution in uploads folder. Add a new .htaccess inside wp-content/uploads/ containing: <Files *.php>
deny from all
</Files> — this prevents uploaded PHP shells from executing.
6. Never use 777 permissions. World-writable folders and files are a critical security risk. If a plugin or tutorial tells you to set 777 permissions, find an alternative solution.

Still need help? Contact UnderHost support →

1. Always take a full backup first. Use UpdraftPlus, Jetpack Backup, or the cPanel backup tool to create a complete snapshot before any update.
2. Update in staging first if you have a staging environment. Test the update on staging before applying to production.
3. Update plugins and themes before WordPress core. Plugin/theme updates often add compatibility for the new core version.
4. Deactivate security plugins temporarily if they're preventing auto-updates — some WAF plugins block update requests.
5. Use Dashboard → Updates to update WordPress core. Read the changelog for any breaking changes before updating major versions.
6. After updating: Clear all caches (plugin cache, Cloudflare, server cache), test all critical pages, forms, and checkout flows.
7. If an update breaks the site: Restore from the backup you took in step 1. Do not update plugins and core simultaneously if you can avoid it.

Still need help? Contact UnderHost support →

1. Identify your backup type: Do you have a cPanel/WHMCS backup, an UpdraftPlus backup, or a manual FTP backup? The restore process differs.
2. cPanel Backup Restore: In cPanel → Backup Wizard → Restore → Home Directory. Then restore the database via phpMyAdmin → Import.
3. UpdraftPlus Restore: Install UpdraftPlus, connect to your backup storage (Dropbox/Google Drive/etc.), and use the Restore button in the plugin.
4. Manual restore: Upload your files via FTP, create/import your database via phpMyAdmin, update wp-config.php with the correct database credentials.
5. Update URLs if moving servers: Use WP Migrate DB or run SQL: UPDATE wp_options SET option_value = replace(option_value, 'old-url.com', 'new-url.com');
6. Test thoroughly after restoration — admin, frontend, forms, cron jobs, and email.
7. Contact UnderHost support if you need help restoring from a server-level backup we hold. We retain rolling backups on most hosting plans.

Still need help? Contact UnderHost support →

1. Install UpdraftPlus. Go to Plugins → Add New → search "UpdraftPlus" → Install and Activate. It's the most widely used WordPress backup plugin with over 3 million active installs.
2. Connect remote storage. In Settings → UpdraftPlus Backups → Settings tab, choose a remote destination: Google Drive, Dropbox, Amazon S3, or FTP. Always store backups off-server. If your server fails, a backup stored on the same server is inaccessible.
3. Set backup schedules. Configure separate schedules for files (weekly) and database (daily). For e-commerce sites, set database backups to every few hours.
4. Set retention counts. Keep at least 4–7 backup copies. This gives you a week's worth of daily backups to roll back to before a problem appeared.
5. Test a restore. After your first backup completes, test the restore process on a staging site. A backup you've never tested is an untrusted backup.
6. UnderHost server backups. UnderHost also takes server-level rolling backups on most plans. Contact support for the backup retention policy on your specific plan, and use UpdraftPlus as an additional off-server layer.

Still need help? Contact UnderHost support →

1. Choose a migration method. For most sites, the All-in-One WP Migration or Duplicator plugin is the easiest option. For large or complex sites, manual migration via FTP + phpMyAdmin gives more control.
2. Using All-in-One WP Migration: Install on the old site, export the full site to a file. Install WordPress + the plugin on the new host, import the file. Note: the free version has a 512MB upload limit.
3. Using Duplicator: Create a package (ZIP + installer.php) on the old site. Upload both files to the new server's web root. Run newdomain.com/installer.php and follow the wizard.
4. Manual migration steps: (1) Export database via phpMyAdmin → Export → SQL. (2) Copy all WordPress files via FTP. (3) Create a new database on the new host, import the SQL. (4) Update wp-config.php with new DB credentials. (5) Update WordPress and Site Address URLs.
5. Search and replace URLs in the database. Use Better Search Replace plugin or WP-CLI: wp search-replace "oldsite.com" "newsite.com" --all-tables
6. Update DNS after testing. Test the new site using a hosts file edit or the host's temporary URL before changing DNS. Only update DNS once the new site is confirmed working.
7. Request a free migration from UnderHost. We offer free website migrations for new customers. Open a migration request ticket or use our Migration Request tool.

Still need help? Contact UnderHost support →

1. Why WordPress emails fail. WordPress uses PHP's mail() function by default. Most shared hosts restrict this to prevent spam abuse, causing notification emails, password resets, and contact form messages to silently fail.
2. Install an SMTP plugin. WP Mail SMTP (by WPForms) is the most popular and reliable option. Install and activate it from the plugin repository.
3. Choose an email sending service. For low-volume sites (under 1,000 emails/month), use your UnderHost cPanel email account as the SMTP server. For higher volume or better deliverability, use SendGrid, Mailgun, or Brevo (free tiers available).
4. Configure WP Mail SMTP. Go to WP Mail SMTP → Settings. Select your mailer, enter your SMTP host (mail.yourdomain.com for cPanel), port (587 with STARTTLS or 465 with SSL), username (full email address), and password.
5. Send a test email. In WP Mail SMTP → Tools → Email Test, send a test to confirm it works. If it fails, the plugin shows the exact error message.
6. Set a proper From address. Use an email address on your own domain (e.g., wordpress@yourdomain.com). Emails sent from a domain that doesn't match your From address are flagged as spam.

Still need help? Contact UnderHost support →

1. Check WooCommerce email settings first. Go to WooCommerce → Settings → Emails. Verify each email type (New Order, Order Confirmed, etc.) is enabled. Check the recipient address is correct.
2. Send a test email from WooCommerce. In WooCommerce → Settings → Emails, click on any email template and use the "Send test email" button. If the test fails, the problem is with PHP mail or SMTP.
3. Set up SMTP. The most common fix for WooCommerce email failures is installing WP Mail SMTP and configuring a proper SMTP server. See the "WordPress Not Sending Emails" article for setup steps.
4. Check for plugin conflicts. Deactivate all plugins except WooCommerce, test email sending, then reactivate plugins one by one. Some security plugins or page builders filter or break the wp_mail() function.
5. Check spam/junk folders. WooCommerce emails sent via PHP mail often land in spam. Setting up proper SMTP with SPF and DKIM records for your domain dramatically improves deliverability.
6. Check your server's SPF/DKIM records. Use UnderHost's Email Diagnostics tool to verify SPF and DKIM are correctly configured for your domain.
7. Contact UnderHost support if emails are still not sending after SMTP setup. We can check server-level mail queue issues or outbound port restrictions.

Still need help? Contact UnderHost support →

1. Why these records matter. SPF, DKIM, and DMARC are DNS records that prove your emails are legitimately sent from your domain. Without them, emails from your WordPress site are likely to land in spam or be rejected outright.
2. SPF record. In your DNS settings (via cPanel or your domain registrar), add a TXT record: v=spf1 include:yourmailserver.com ~all. If using UnderHost mail servers, cPanel AutoSSL usually configures this automatically.
3. DKIM record. In cPanel → Email → Email Deliverability, find your domain and click "Repair". This generates and installs the DKIM key in your DNS automatically.
4. DMARC record. Add a TXT record for _dmarc.yourdomain.com with value: v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com. Start with p=none (monitor mode) before switching to p=quarantine or p=reject.
5. Verify with Email Diagnostics. Use UnderHost's Email Check tool to verify SPF, DKIM, and DMARC are correctly set for your domain.
6. Use a dedicated sending domain. For high-volume transactional email, use a subdomain like mail.yourdomain.com for sending. This protects your main domain's reputation if emails are marked as spam.

Still need help? Contact UnderHost support →

1. Check spam/junk folders first. Before troubleshooting, check the recipient's spam folder. If form emails are there, the issue is deliverability, not sending.
2. Test with WP Mail SMTP's Email Log. WP Mail SMTP (Pro) logs all outgoing emails. Even the free version shows whether the email was handed off to the mail system. Install it and check if emails are being sent at all.
3. Configure SMTP sending. Contact forms (Contact Form 7, WPForms, Gravity Forms, etc.) all use wp_mail(). Installing WP Mail SMTP with a proper SMTP provider fixes deliverability for all of them at once.
4. Check the From email address. The from address must be on your own domain. Using a Gmail or Hotmail from address while sending from your server causes immediate spam flagging.
5. Test the form plugin settings. In Contact Form 7: verify your Mail tab settings. In WPForms: check Notifications settings. Ensure the "Send To" email address is correct and notifications are enabled.
6. Check for a PHP mail block. Some hosts block PHP mail entirely. In cPanel → Track Delivery, send a test and see if there's an outbound block. Setting up SMTP bypasses PHP mail entirely.
7. Try a different form plugin. If one form plugin is consistently failing, try an alternative. WPForms and Fluent Forms both have solid track records for email reliability.

Still need help? Contact UnderHost support →

1. Complete the Setup Wizard. After activating WooCommerce, run the built-in Setup Wizard (WooCommerce → Home). It walks you through store address, currency, payment methods, shipping, and tax configuration.
2. Configure your payment gateway. Go to WooCommerce → Settings → Payments. Enable Stripe (for card payments) and/or PayPal. Both have free official plugins. For test mode, enable "Test mode" before going live.
3. Set up shipping zones and rates. In WooCommerce → Settings → Shipping, create zones for the regions you ship to and add flat rate, free shipping, or local pickup options.
4. Configure tax settings. In WooCommerce → Settings → Tax, enable taxes if required. Use the WooCommerce Tax plugin (free) or TaxJar for automated tax calculation based on customer location.
5. Install WooCommerce store pages. WooCommerce needs four pages: Shop, Cart, Checkout, and My Account. These are created automatically, but verify they exist under Pages and are assigned in WooCommerce → Settings → Advanced.
6. Set up transactional emails. In WooCommerce → Settings → Emails, verify all email templates are enabled and the recipient addresses are correct. Configure SMTP (see WooCommerce Emails article) before processing real orders.
7. Test the full checkout flow. Before launching, place a test order using Stripe's test card (4242 4242 4242 4242) or PayPal sandbox. Confirm the order appears in WooCommerce → Orders and all emails arrive.
8. Install an SSL certificate. WooCommerce requires HTTPS for checkout. UnderHost provides free AutoSSL on all plans — verify it's active in cPanel → SSL/TLS before accepting payments.

Still need help? Contact UnderHost support →

1. Check the checkout page assignment. Go to WooCommerce → Settings → Advanced. The Checkout page must be set to a page that contains the [woocommerce_checkout] shortcode (or the WooCommerce Checkout block). If this page was deleted or reassigned, checkout breaks.
2. Deactivate all non-WooCommerce plugins. Plugin conflicts are the most common cause of a broken checkout. Deactivate all plugins except WooCommerce, test checkout, then reactivate one by one. Caching, security, and page builder plugins are frequent culprits.
3. Switch to a default theme. A poorly coded theme can break WooCommerce templates. Activate Storefront (the official WooCommerce theme) or Twenty Twenty-Four and test checkout.
4. Clear all caches. A blank checkout page is often just a stale cached version. Clear your caching plugin, Cloudflare, and browser cache. Always exclude /checkout/ from your cache rules.
5. Check for JavaScript errors. Open DevTools (F12) → Console on the checkout page. WooCommerce checkout relies heavily on JavaScript. Errors in the console point to the conflicting script.
6. Verify PHP memory. The checkout page loads payment gateways, shipping calculators, and cart data. Low memory causes a silent blank page. Increase WP_MEMORY_LIMIT to 256M in wp-config.php.
7. Regenerate WooCommerce pages. Go to WooCommerce → Status → Tools → Create default WooCommerce pages. This recreates missing or broken core pages.
8. Contact UnderHost support if the checkout is broken after a PHP or server update — sometimes WooCommerce extensions have strict PHP version requirements.

Still need help? Contact UnderHost support →

1. Check if the gateway is enabled and configured. Go to WooCommerce → Settings → Payments. Click "Manage" next to your gateway and confirm it's enabled, API keys are entered, and it's not in Test Mode (unless testing).
2. Verify SSL is active. Stripe and PayPal require HTTPS. If your checkout page is serving over HTTP, or if you have mixed content warnings, the payment gateway will refuse to load. Check in your browser's address bar for a padlock.
3. Stripe-specific: check API keys. Ensure you're using the correct Publishable and Secret keys for the correct mode (live vs test). Log into Stripe → Developers → API Keys to confirm. Never use test keys in production.
4. PayPal-specific: check IPN settings. Go to your PayPal account → Account Settings → Notifications → Instant Payment Notifications. The IPN URL should point to your site's /wc-api/WC_Gateway_Paypal/ endpoint.
5. Check for plugin conflicts. Security plugins that add CSP headers or block external scripts can prevent payment gateway iframes from loading. Temporarily deactivate security plugins and test.
6. Test with WooCommerce System Status. Go to WooCommerce → Status → check the "Payment Gateways" section. It shows whether gateways are active and flags any configuration issues.
7. Check your currency. Some payment gateways don't support all currencies. Stripe supports most major currencies; PayPal Standard doesn't support all. Verify your store currency in WooCommerce → Settings → General.
8. Contact your payment gateway's support with the exact error message shown in WooCommerce → Status → Logs (select the gateway log from the dropdown).

Still need help? Contact UnderHost support →

1. Flush rewrite rules. Go to Settings → Permalinks → Save Changes (no change needed, just save). This regenerates the .htaccess rewrite rules and is the fix in the majority of WooCommerce 404 cases.
2. Check the Shop page assignment. In WooCommerce → Settings → Products → General, ensure the "Shop page" is set to your actual Shop page. If it's blank or points to a deleted page, product archives return 404.
3. Check product visibility. Edit the product and check the "Catalog visibility" setting in the Product Data panel → Catalog visibility. Products set to "Hidden" or "Search only" won't appear on the Shop page.
4. Verify product is published. Draft, private, or scheduled products won't appear to visitors. Check the product status in the top-right of the product editor.
5. Check stock status. If "Hide out-of-stock items" is enabled in WooCommerce → Settings → Products → Inventory, out-of-stock products disappear from the shop. Either re-stock or disable this setting.
6. Deactivate caching plugins and test. Cached versions of the shop or category pages may not reflect newly added products. Clear all caches or temporarily deactivate your caching plugin.
7. Check for conflicting plugins or theme archive templates. Some themes override WooCommerce product archive templates incorrectly. Switch to Storefront and test.
8. Check WooCommerce page templates. Go to WooCommerce → Status → Templates. If any WooCommerce template files have been overridden by your theme and are outdated, they're listed here. Outdated templates can cause display issues.

Still need help? Contact UnderHost support →

1. What "Pending Payment" means. The customer reached checkout and an order was created, but payment was never confirmed. This can mean the customer abandoned checkout, the payment failed silently, or the payment gateway callback (IPN/webhook) didn't reach your site.
2. Check WooCommerce → Orders for the order details. Look at the order notes at the bottom of the order. They record exactly what happened — you'll see if payment was attempted, declined, or the callback failed.
3. Verify your site is reachable from the payment gateway. Stripe and PayPal send a webhook/IPN to your site to confirm payment. If your site has basic auth protection, is behind a firewall, or returns errors to the webhook URL, confirmations never arrive.
4. For PayPal: check IPN delivery. Log in to PayPal → Account Settings → Notifications → Instant Payment Notifications → IPN History. You can see if IPNs were sent to your site and whether they succeeded or failed.
5. For Stripe: check webhook delivery. In Stripe Dashboard → Developers → Webhooks, check the event log. Failed webhooks are listed. Your webhook endpoint is usually https://yourdomain.com/?wc-api=wc_stripe.
6. Manually update stuck orders. For legitimate paid orders that are stuck, you can manually change the status to "Processing" in the order editor. Then trigger the customer email manually.
7. Set up automatic payment complete via WP-Cron. WooCommerce has a built-in hook to clear pending orders after a set time. Ensure WP-Cron is running (or use a real cron job) so WooCommerce can process order status transitions.
8. Contact UnderHost support if your server firewall is blocking incoming POST requests from payment gateway IP ranges. We can check and whitelist Stripe/PayPal IP blocks.

Still need help? Contact UnderHost support →

1. Exclude WooCommerce pages from full-page cache. Cart, checkout, and My Account pages must never be cached. In your caching plugin settings, add these to the exclusion list: /cart/, /checkout/, /my-account/. Caching these pages breaks cart totals and checkout flow.
2. Use a compatible caching solution. LiteSpeed Cache and WP Rocket both have WooCommerce-specific modes that handle fragment caching (e.g., caching the page while keeping the cart widget dynamic). Standard full-page caches without WooCommerce support cause cart and checkout issues.
3. Enable Redis object cache. WooCommerce runs many database queries per page. Redis object caching dramatically reduces database load. Ask UnderHost support about enabling Redis on your plan.
4. Optimise product images. WooCommerce product images are loaded on every shop and category page. Use Imagify or ShortPixel to compress and convert images to WebP. Enable lazy loading.
5. Limit WooCommerce product variations. Products with hundreds of variations generate very large variation JSON payloads embedded in the page. Keep variations under 50 per product or use the WooCommerce Variation Swatches plugin to load variations on demand.
6. Archive and clean up old orders. WooCommerce stores all order data in wp_posts and wp_postmeta. Thousands of old orders slow queries. Use the WooCommerce Order Archiving feature or a cleanup plugin to archive/delete orders older than 1–2 years.
7. Consider a dedicated WooCommerce hosting plan. High-traffic stores need resources beyond shared hosting. Ask UnderHost about WooCommerce-optimised VPS and managed hosting plans.

Still need help? Contact UnderHost support →