cleancoded

Internal server errors (error 500) are often caused by plugin or theme function conflicts, so if you have access to your admin panel, try deactivating all plugins. If you don’t have access to your admin panel, try manually resetting your plugins (no Dashboard access required). If that resolves the issue, reactivate each one individually until you find the cause.

If that does not resolve the issue, try switching to the default theme for your version of WordPress to rule-out a theme-specific issue. If you don’t have access to your admin panel, access your server via SFTP or FTP, or a file manager in your hosting account’s control panel, navigate to /wp-content/themes/ and rename the directory of your currently active theme. This will force the default theme to activate and hopefully rule-out a theme-specific issue.

If that does not resolve the issue, it’s possible that a .htaccess rule could be the source of the problem. To check for this, access your server via SFTP or FTP, or a file manager in your hosting account’s control panel, and rename the .htaccess file. If you can’t find a .htaccess file, make sure that you have set your SFTP or FTP client to view invisible files.

If you weren’t able to resolve the issue by either resetting your plugins and theme or renaming your .htaccess file, we may be able to help, but we’ll need a more detailed error message. Internal server errors are usually described in more detail in the server error log. If you have access to your server error log, generate the error again, note the date and time, then immediately check your server error log for any errors that occurred during that time period. If you don’t have access to your server error log, ask your hosting provider to look for you.

I would create both a /blog page and an /all page, make /all a child of /blog, set the /blog/all page to be the main blog page, and then set up a 301 redirect for /blog to redirect to /blog/all — would that work for you?

Your ‘Products’ and ‘Support’ pages are both redirecting to other pages (that you aren’t linking to). So, those would technically be orphaned, you’re not linking to the destination pages.

If you’re seeing this error either suddenly (no specific task was done to cause the error) or frequently, try deactivating all plugins to rule-out a plugin-specific issue and try switching themes to rule out a theme-specific issue.

Otherwise, here are three ways to increase PHP’s memory allocation:

1. If you can edit or override the system php.ini file, increase the memory limit. For example, memory_limit = 128M

2. If you cannot edit or override the system php.ini file, add php_value memory_limit 128M to your .htaccess file.

3. If neither of these work, it’s time to ask your hosting provider to temporarily increase PHP’s memory allocation on your account.

(in the above examples, the limit is set to 128MB)

I see that you’re using WPBakery Page Builder. Are you able to successfully edit pages and posts if you deactivate that plugin?

Does the issue persist after deactivating all plugins, reverting to default theme, and following the 3 steps outlined above? I know you’re editing a live site, with a caching plugin installed, so this may be hard to do. Do you want to try setting up a staging environment with a copy of the live site and try deactivating theme/plugins to troubleshoot there?

This is probably part of your testing currently in progress, but I’m seeing a 404 error when clicking on any links to any other posts or pages on your site from the homepage.

This may be a plugin or theme conflict.

You could try installing the “Health Check” plugin (https://ww.wp.xz.cn/plugins/health-check/) which allows you to troubleshoot your site without having any affect on your normal visitors. Open your site in an incognito window to verify this.

Then, while in troubleshooting mode, from the Plugins page, click the “Enable while troubleshooting” for WooCommerce, and see if your /shop page displays product prices without any other plugins activated (still in troubleshooting mode, which is not affecting your visitors).

If your site does display product prices correctly, then try enabling your other plugins (and then your theme) one by one to see which one is responsible for the conflict.

The previously used page and post slugs are stored in the database in the wp_postmeta table. Check for _wp_old_slug in the meta_key column (the actual slugs being stored in the meta_value column). If you want this default behavior not to happen in a particular case, this is where to delete a value and search for “used” URLs.