How to diagnose a 500 error after moving WordPress

A server error after migration needs evidence from the relevant logs. Check database credentials, paths, permissions, PHP compatibility and required extensions in a controlled sequence. Avoid changing every setting at once or using unrestricted permissions as a general repair. Verify the original failing request after each relevant correction.

This guide combines a task-specific answer and action checklist with a supporting technical reference. Use the sections relevant to your situation, verify current product and platform details, and keep the customer journey in view. The aim is to make a sound decision and check the result, rather than assume that one purchase or setting solves every related problem.

A practical sequence for this specific task

Work through the topic-specific checks below in a controlled order. They identify the decisions that matter for this task, including the dependencies or limitations that can be missed when attention goes only to a headline product or the most visible symptom.

1. Read relevant logs.
2. check permissions without suggesting 777.
3. PHP extensions.
4. database credentials.
5. restore backups safely.

Use the sequence as an assessment checklist, then consult the current instructions for the exact platform or service involved. Confirm access and recovery before a change, record the starting position and test the relevant customer or administrator workflow afterwards. If a step involves production data or an irreversible action, establish a safe method before proceeding.

Change PHP and application settings with compatibility checks

PHP is part of the environment that runs many WordPress websites. Changing its version or limits can affect themes, plugins and custom code, so a setting change should be treated as an application compatibility task. Check the current support requirements of the actual software installed, then test the intended environment before changing a live business site.

Use error logs to understand failures. A blank page, a server error and a timeout can have different causes, including missing extensions, incompatible code, incorrect paths or an application exhausting a resource limit. Do not assume that increasing a memory or execution limit is the correct response to every problem. It may temporarily conceal a faulty or unexpectedly expensive task.

Make one relevant change at a time and record the old value. Review whether the hosting platform applies settings per domain, per account or through a particular configuration file. A value saved in one interface may not be the value actually used by the affected application. Verify the live environment through an appropriate diagnostic method and remove any public diagnostic file afterwards.

Test important workflows after the change, including administration, uploads, forms and scheduled jobs. Keep a practical rollback route if the new environment exposes incompatibilities. Use currently supported software and seek application-specific guidance when an extension or custom integration prevents a straightforward change.

Use logs and scheduled-task timing to find recurring faults

Logs are useful when they are connected to a specific symptom and time. Record the URL, action, error and approximate timestamp before investigating. Web server logs, application logs and provider resource information can then help distinguish a request problem from a scheduled task, an external dependency or a configuration change.

Check recurring jobs such as backups, imports, reports and application maintenance. A site that slows at the same time each day may be competing with background work rather than running out of capacity continuously. Review whether multiple jobs overlap, whether a failed job retries excessively and whether the schedule reflects actual business needs.

Treat logs as potentially sensitive. They may contain identifiers, request details or information that should not be shared publicly. Remove unnecessary personal data when asking for help, and keep access and retention appropriate to the environment. Avoid pasting secrets or complete customer records into a support request simply because they appear near the error.

Test a proposed fix against the original timing pattern. Rescheduling one task or correcting one integration should produce an observable difference in the affected period. Keep enough evidence to understand the result, and resist disabling every job at once. That can hide the fault while introducing new problems such as missed backups or delayed business processes.

Investigate the database without deleting live information

The database can affect both speed and reliability. Slow queries, large tables, repeated background work and inefficient application code may make a WordPress site sluggish even when the hosting environment is otherwise healthy. Begin by identifying the affected workflow and examining relevant logs or diagnostic information, rather than deleting records simply because a table looks large.

Take a recoverable backup before database maintenance. Test proposed changes away from production and understand which application owns each table. Revisions, transient data and historical logs are different from orders, account records and configuration. A general cleaning tool cannot decide which information your business still needs or which records an integration expects to find.

Where query timing is available, use it to identify repeated or expensive requests. A high query count is not automatically a problem, and one apparently simple query can be costly on a large data set. Investigate the application behaviour that creates the workload, including searches, reports, imports and scheduled jobs. Avoid making structural changes unless you understand their consequences.

After maintenance, verify the business data and workflows. Check content, logins, orders or memberships as appropriate, and compare performance against the original symptom. Keep a record of what changed and how it was tested. If the task involves repairing production transactions or altering application tables directly, involve someone with the relevant database and application expertise.

Prepare a backup that can actually be restored

Before changing hosting or application settings, take a backup that covers both files and the relevant database. A collection of theme files without the database is not a complete WordPress recovery plan. Conversely, a database export without uploads and configuration may restore the text but leave the website incomplete. Record what is included and which services are outside the backup's scope.

Store a protected copy away from the system being changed. A backup kept only inside the same hosting account may be unavailable during an account problem, and an unprotected database export inside a public directory can expose information. Use access controls appropriate to the data, remove temporary public copies and keep credentials separate from the archive.

Test restoration in a separate environment when possible. Confirm that the database imports, files are readable, the application can connect and important pages work. For a shop, test the restored structure without accidentally replaying real payments or sending customer messages. A successful download proves you have an archive; it does not prove the application can be recovered from it.

Keep the source hosting account available until the destination has passed the agreed checks. Document the backup time, the restoration steps and the person responsible for recovery. If the site receives new transactions after the backup, plan how to preserve or reconcile that newer data before using an older copy as a rollback.

Test changes away from live customer activity

A staging environment gives you a place to test compatibility, configuration and content changes without using customers as the test group. It should resemble the relevant parts of production closely enough to reveal likely problems. A test on a completely different software stack may be useful, but it cannot confirm that the live hosting environment will behave identically.

Protect staging from public indexing and unauthorised access. Search visibility controls help prevent accidental discovery, but they are not a substitute for access control when the environment contains sensitive information. Review whether the test copy includes customer records, live API credentials or working email and payment integrations, and remove or isolate those where appropriate.

Test the workflows that matter, not just the homepage. Check administrator access, forms, uploads, scheduled tasks and the application features people use day to day. A WordPress shop needs particular attention to cart, checkout and account behaviour. A membership site needs tests for both logged-out and logged-in visitors with different permission levels.

Be careful when deploying changes back to production. Copying a staging database over a live database can remove orders or registrations created after the staging copy was made. Decide whether the release requires files, settings, selected content or a full database change, and use a deployment process suited to that scope. Keep a record of exactly what was deployed.

Separate server delay from browser work

A slow website can have several independent causes. The server may take too long to generate a response, the network may take time to deliver it, or the browser may spend too long loading and rendering assets. Looking only at the final page load time can hide these distinctions and lead to an upgrade that does not address the main bottleneck.

Compare server response timing with the size and complexity of the page. Large images, many scripts and expensive browser work can make a page feel slow even when the hosting responds promptly. Conversely, a simple page can still have a long initial delay because the application is waiting on database queries, external requests or constrained server resources.

Use repeatable tests with comparable conditions. Keep the page, device type and approximate network conditions consistent when measuring before and after a change. Check representative pages rather than choosing only the fastest one. For WordPress, compare public pages with the administrator area, because front-end caching may hide issues that remain visible to logged-in users.

Avoid interpreting one test as a complete diagnosis. Check logs and resource information alongside timings, and note when the problem occurs. A site that is slow only during backups or a scheduled campaign needs a different investigation from one that is slow throughout the day. Combine the measurements to identify the most likely next action.

Understand capacity limits and concurrency

Hosting limits can involve CPU time, memory, storage, disk operations, process counts or connection limits. They are not interchangeable. A website can have unused disk space while exhausting the number of concurrent requests the plan can handle. Read the provider's current definitions and limits, then relate them to the actual error or performance symptom you are investigating.

Look for patterns over time rather than a single peak. Correlate resource warnings with requests, scheduled tasks, traffic sources and application errors. Bots, long-running jobs or a malfunctioning plugin can consume capacity without representing useful customer demand. Removing the cause may be more effective than paying for a larger plan that will eventually hit the same problem.

Consider concurrency as well as daily visitor totals. A store with many simultaneous uncached checkouts can place more pressure on an application than a much larger number of visitors reading cached articles throughout the day. Logged-in pages, searches and personalised functions often behave differently from public static content, so test the workload that matters to the business.

An upgrade becomes more persuasive when there is evidence of sustained legitimate demand after obvious inefficiencies have been addressed. Compare suitable options against the workload, required administration and recovery arrangements. Do not treat descriptions such as unlimited as a promise of unlimited application performance; review the specific plan's terms and resource boundaries.

Use caching where it is safe and useful

Caching can reduce repeated work by serving a previously prepared response, but different caches solve different problems. Browser caching controls reuse on the visitor's device. Page caching can reuse generated HTML. Other application-level caches may reduce database or computation work. Understand which layer you are changing before using it as a general explanation for every speed problem.

Identify the pages and requests that should remain personalised. Carts, checkout, logged-in account pages and permission-sensitive content need particular care. Serving one person's cached state to another person is a correctness and privacy problem, even if the page appears faster. Follow the application and caching tool's current exclusion guidance, then verify the actual behaviour with separate test accounts.

Plan cache invalidation as well as cache creation. Prices, availability, content changes and deployments should appear when expected. A stale page may look like an application error even when the underlying data is correct. Know how to purge the relevant cache and distinguish it from the browser cache or a separate delivery-network cache.

Measure the result on representative pages. Caching will not necessarily speed up the WordPress administrator area or fix a long-running external request. Check uncached workflows separately and monitor for incorrect behaviour. Keep the settings understandable so that another administrator can troubleshoot a later change without disabling everything at once.

Write down the outcome before choosing a product

Begin with a small requirements document that describes the result the business needs. A useful requirement is observable: a customer can submit an enquiry on a phone, a team member can receive a message at the company domain, or an administrator can restore a website in a test environment. Phrases such as professional, fast and secure are useful aspirations, but they need more precise acceptance checks before they can guide a purchase or a technical change.

Separate essential requirements from preferences. The essential list might include control of the account, support for the existing application, a documented renewal process and a working recovery route. A preference could be a familiar interface or a particular visual style. This distinction makes it easier to compare solutions without paying for features that do not solve the immediate problem.

Record dependencies as well as features. A domain can be registered with one provider while the website and email run elsewhere. A website form may depend on an external sending service. A booking workflow may depend on staff calendars. Looking at these relationships prevents a change in one service from unexpectedly interrupting another.

Assign an owner to each acceptance check and write down the evidence needed to pass it. A screenshot of a setting is useful, but an actual completed test is stronger evidence that the workflow works. Keep credentials outside the requirements document and store the document somewhere the appropriate team can find it during a handover.

Measure the result against a sensible baseline

Record the starting position before changing a system. For a technical problem, that might be a response time, an error message, a delivery failure or a timestamp from a log. For a business website, it could be the number of qualified enquiries, the steps needed to complete a form or the percentage of visitors who reach a useful page. Choose measures that reflect the actual problem.

A baseline makes it easier to distinguish improvement from normal variation. One fast page load or one successful email is not enough to prove a persistent issue has been resolved. Repeat the important checks under representative conditions, including the devices, account types and locations your customers actually use. Explain any limitations in the test rather than turning a small sample into a broad performance claim.

Change one major variable at a time when that is practical. If the hosting plan, application configuration and website design all change together, it becomes harder to tell which change helped or created a new problem. Keep a brief log of actions and results so another person can understand the reasoning later.

Review both benefits and side effects. A faster public page is not a successful change if checkout stops working; a simpler form is not useful if submissions never reach the team. Agree a follow-up date, compare the outcome with the baseline and decide whether to keep, adjust or reverse the change based on evidence.

Worked hypothetical example

Consider a hypothetical project involving an agency moving a client's site between hosting environments. This example illustrates a decision process; it is not a claim about a real Trodomains customer or a measured result. The project owner first records the relevant services and accounts, then defines the action that needs to work at the end. The owner keeps any unrelated service in scope for continuity checks without moving it unnecessarily. The team writes down the current position and selects a small test that represents the important workflow. If the test fails, it records the specific stage and investigates that evidence instead of buying an unrelated upgrade or making several new changes together. Once the cause or requirements are clearer, the team compares a suitable service against the real operating responsibilities and current terms. The final check follows the user journey through to its business outcome, not merely to an attractive page or a saved setting. The owner records the outcome and any limitations, assigns follow-up work and keeps the recovery information accessible to the right people. The useful lesson is the method: define, test, verify and retain control. The time, cost and result would depend on the actual project.

Decision and verification checklist

Keep the evidence proportionate to the decision. For a simple content change, a recorded review and end-to-end check may be enough. A production migration, account-security event or transactional recovery can need a more detailed record and relevant technical expertise. Do not use the table as permission to make a destructive change without understanding its scope.

Before closing the task, confirm who now owns routine operation, which notices they receive and where the recovery instructions are kept. Check that access no longer depends on an obsolete supplier or staff account. Set a follow-up review against the original objective and keep unresolved points visible. Successful operation means the business can maintain the result, not only that the initial change was completed.

Frequently asked questions

Does a larger hosting plan automatically fix the problem?

No. A capacity upgrade is useful when the workload exceeds the suitable resources, but it does not necessarily fix incorrect DNS, application errors or inefficient code. Identify the failing stage and compare it with resource and timing evidence. Keep the proposed upgrade connected to the measured requirements and the operating responsibility it introduces.

Should the current hosting be cancelled immediately?

Keep the source environment available until the destination and any required data synchronisation have passed verification. Check the current cancellation and billing terms, and make an informed decommissioning decision. Website files, database records, email and external services may have different continuity requirements, so one successful homepage check is not enough.

What should be tested before calling the change complete?

Test the workflows the business actually uses: relevant public pages, administrator access, forms, uploads, background jobs and transactional or membership functions where applicable. Use controlled tests and keep live payments and customer messages out of staging. Compare the result with the original symptom, and record any unresolved dependency rather than treating it as an invisible exception.

Can this work be done without technical help?

Some routine control-panel tasks can be completed by a careful owner following the platform's current instructions. Production database repair, transactional recovery or server administration can require specialist expertise. The decision should depend on the scope, available recovery resources and consequences of an error. Seek help before a destructive step that the team cannot confidently reverse.

How should suitable hosting products be compared?

Compare the current plans against application compatibility, expected workload, access, management scope and recovery needs. Review actual pricing and renewal terms on the product page. Do not treat visitor counts, disk space or a marketing label as a complete specification. A suitable service is one the business can operate reliably for its real workflows.

Your next steps

Return to the original question and confirm that the chosen action addresses it. Review the task-specific checklist, the relevant evidence and any outstanding dependency before calling the work complete. Keep the result connected to the business workflow that prompted the investigation.

Trodomains provides a relevant service destination for this guide. Compare its current details, price, renewal terms and management scope with your requirements before ordering. If the issue is configuration, content or process rather than a missing service, resolve that cause first. Keep the final checks and ownership notes so the result can be maintained.