The short answer: if your visitors are mainly based in Hungary, then yes. In this article, we won’t be going through the registration process (that’s covered in our guide to .hu domain rules), but rather what a .hu domain offers your business, when you might need a different extension, and how much it costs to maintain. You can also check the prices and availability on our .hu domain registration page.
At first glance, the .hu extension indicates that this is a Hungarian-language service operating in Hungary. The majority of Hungarian internet users instinctively trust such websites more, particularly when they are required to provide payment details or personal information:
Of course, a .hu domain in itself is no guarantee of anything, but visitors are entitled to expect that behind a .hu website there is a Hungarian-language support team and a business operating in accordance with Hungarian law. In the age of ‘fake online shops’, this impression counts for a great deal, and an email address with the .hu extension, info@cegem.hu, also reinforces this sense of trust in your correspondence.
Google treats country code extensions (ccTLDs) as geographical indicators: it assumes that a .hu website is primarily aimed at Hungarian users. This is no magic bullet; rankings are still determined by the quality of the content, the technical condition of the site and backlinks, but for a site aimed at a Hungarian audience, the .hu extension is a natural and good starting point. For a .com site, the same targeting must be achieved through language, content and hreflang tags.
AI-based search engines and assistants also draw on web-based sources, so it is equally important for them that content is authoritative, well-structured and clearly identifiable. An easy-to-remember .hu domain name that fits your brand helps with this too.
If someone else registers your business name with a different extension, it can easily confuse your customers; in the worst case, it could be used as the basis for phishing sites. That is why many companies purchase the .com and .eu versions of the same name alongside the .hu version, but only actively use the .hu domain, redirecting the others to it. This way, no one else can capitalise on their name, and they won’t have to look for a new name should they expand in the future.
If your chosen name is already taken directly under .hu, it may still be available amongst the second-level generic domains (such as .co.hu, .info.hu, .shop.hu). These are fully-fledged addresses, but visitors are less familiar with them; therefore, for a new brand, it is often better to look for a name that is slightly different but available under .hu.
The .com extension suggests an international presence, whilst .eu suggests a European one. If you’re only targeting the Hungarian market, .hu is the right choice, and there’s no need to start with a foreign extension. However, it’s worth registering a .com or .eu domain (as well) if:
In our article on .com domain registration, written from a .com perspective, we discussed in detail when it is worthwhile for a Hungarian company.
The .hu domain is not just for Hungarian companies: any citizen or legal entity from any country may apply for one; however, applicants from outside the EU, the EEA and neighbouring countries must prove that the use of the domain is justified by economic or other activities. As a natural person, you must be at least 18 years of age. Following your application, the domain will be provisionally registered, and if no objections are raised within 8 days, the registration will become final. Full details are set out in our knowledge base article on the rules for .hu domain registration.
The fee for a .hu domain varies by registrar and is payable annually. With us, registering a .hu domain costs €5.44, its renewal costs €5.44, and its transfer costs €5.44 per year (prices exclude VAT).
When choosing a registrar, don’t just look at the first year’s fee, but also at how much the renewal costs. It can happen that the first year is cheap, but from the second year onwards you have to pay considerably more. A reputable registrar will clearly display the renewal price. We’ve written in more detail about the prices of domain extensions in our article on domain prices.
If your business is focused on the Hungarian market, a .hu domain is still well worth it: it inspires confidence, signals your target audience to search engines, and is inexpensive to maintain. If you plan to expand abroad in the future, it’s worth registering the .com or .eu versions now and redirecting them to the .hu domain. You can check availability in our domain search tool in just a few seconds.
]]>Before updating, it is important to check whether your website and plugins are compatible with the new version of PHP. Checking compatibility, taking a backup and testing after the switch will help minimise the risk of errors.
In this guide, you’ll find out where to locate the PHP settings in cPanel, how to select a version, and what to do if your website displays an error after the change. We’ll also show you how to revert to a previous PHP version, and when it’s advisable to check compatibility in a test environment first.
You can assign different PHP versions to domains and subdomains if they appear on separate lines in the MultiPHP Manager. The supported versions vary by hosting plan; for example, the list may include PHP 8.3 or PHP 7.4.
Log in to cPanel, then open the MultiPHP Manager menu item. If this feature is available, you can manage PHP settings on a per-domain basis. If you have multiple hosting accounts, check that you are logged into the correct cPanel account. Before making any changes, make a note of the domain’s current version.
If you cannot find the MultiPHP Manager menu item, look for the ‘Select PHP Version’ option. The cPanel interface may vary depending on your provider’s configuration, and it may be that the PHP settings cannot be changed. If neither menu item appears, or if the setting is locked, please contact your hosting provider’s support team.
Find the domain in the list for which you wish to change the PHP version. Tick the corresponding box, then check the domain name. If you select multiple domains, the same version will be applied to all of them. To update a single website, simply select its row.
Please also check the domain’s current PHP version in the table. If you have multiple websites, subdomains or test sites, do not assume that they all use the same settings. You can select a subdomain appearing on a separate line individually, so that the main domain’s version remains unchanged.
Select the desired, available PHP version from the drop-down menu for the selected domain. In MultiPHP Manager, for example, you can choose between PHP 8.3 and PHP 7.4, but the actual list depends on your hosting settings. The currently supported versions are shown in the options displayed in cPanel.
Click the ‘Apply’ button to apply the setting. If the version you want is not listed, or if you are unable to apply the change, please contact your hosting provider’s support team. Do not attempt to override the setting managed by cPanel by modifying other files.
If your websites require different versions of PHP, configure them individually. Select one of the domains, choose the required version for it, then apply the change. Repeat these steps for the next domain. This way, the main domain and the subdomain listed on a separate line can use different versions.
Do not select all domains if you only wish to change the settings for one of them. The same PHP version will apply to all selected domains. If the subdomain does not appear separately, check the domain entries visible in cPanel before applying the change.
Before updating, make a backup and check your website’s compatibility. Changing the PHP version does not in itself delete any files, but an incompatible plugin may cause a malfunction.
Don’t switch just because a newer version of PHP is available. First, check whether your website’s code, plugins and templates are compatible with it. The website’s documentation or information from the developer can provide guidance on this. If it is unclear whether your website supports the version, try the upgrade in a test environment first, rather than on the live site. This will help you determine whether further compatibility checks are needed. Don’t just check whether the page loads; also check that the chosen PHP version works correctly with all the important elements of your website.
Changing the PHP version does not in itself delete your website’s files, but the site may become temporarily unavailable due to a compatibility issue. The fact that the files remain intact therefore does not guarantee error-free operation. If testing or the documentation indicates incompatibility, do not treat the switch as a risk-free routine task. Check the information provided by the developer and only proceed once you have clarified whether the website supports the new version. If compatibility remains unclear, stick to the test environment until the issue is resolved. This way, you can base your decision on the website’s actual performance.
If your website is not working properly after changing the PHP version, revert to the version you were using previously. In cPanel’s MultiPHP Manager, select the domain again and apply the previous settings.
In cPanel, you can change the PHP version via the MultiPHP Manager or the Select PHP Version interface. In the PHP Selector, select the desired version and then set it as the current one.
After the switch, allow some time for the changes to take effect: this takes a few seconds. During this time, do not immediately assume the change has failed, and do not initiate another version change simply because the interface does not yet reflect your selection. After waiting, return to check that the domain in question is functioning correctly, and assess the result of the configuration according to the compatibility criteria mentioned earlier. Due to the short turnaround time, it is advisable to wait patiently until the operation is complete, and only then to assess whether the desired version has taken effect. If you carry out further checks, be sure to distinguish between the fact that you are waiting and your assessment of the website’s actual behaviour.
Updating the PHP version involves more than just selecting a new version. It is advisable to change the setting in cPanel only if your website’s software supports the desired version, and then check that the site is working correctly.
aWh offers web hosting for websites and online projects. If you are unable to change the PHP settings in cPanel, or if you encounter an error after changing the version, please contact aWh’s support team with any hosting-related queries. When selecting the appropriate PHP environment, the website’s software, the compatibility of plugins and the settings available in cPanel are all important factors to consider.
When choosing a web hosting provider, ease of use and the option of backups are also important considerations. aWh offers web hosting, KVM VPS, domain registration and email hosting. You can find out more about cPanel management and hosting solutions tailored to your website’s needs in the details of aWh’s web hosting services.
Take a look at aWh’s web hosting options and choose the solution that best suits your website.
After modifying your PHP settings, keep a record of the maintenance work. Note down the date of the change, the website affected and any error messages. This will allow you to compare the technical changes with any changes you notice in the website’s performance later on.
If the ‘Allowed memory size exhausted’ error persists even after checking your PHP settings, investigate which operation or extension is using too much memory. Updating the PHP version in cPanel alone will not resolve the issue of exceeding the memory limit. Reviewing the error log and the circumstances of the error may help you determine the next step in your investigation.
If you have any technical queries, please contact aWh. This will allow you to base your next maintenance step on the website’s actual performance.
The correct cPanel interface depends on how PHP settings are managed on the hosting account. If the website runs on a separate domain, look for a setting that assigns the PHP version to that domain. If the interface only shows one current version, check whether this applies to all websites or only to the selected one. The description of the control panel may help with this.
Incompatibility does not necessarily render the entire website inaccessible. It may be that only one function, such as file uploading or an administrative operation, is failing. Make a note of the exact error message, the page affected and the action that preceded it. This information can help distinguish between an error related to PHP code and a database or permissions issue.
Make a note of when and on which page the error occurred. Try performing the relevant action in a different browser, then check whether the error can be reproduced. Use the file name or error message in the log to locate the relevant component. If the business functionality of the page is compromised, restrict use of the affected functionality until the issue is resolved.
A newer version of PHP may include enhancements that enable a more up-to-date software environment. However, upgrading does not replace the need for code optimisation, nor does it automatically increase the PHP memory limit. If you encounter an ‘Allowed memory size exhausted’ error, check which process is consuming a lot of memory, such as large image processing or a particular plugin.
With this update, your website can operate in a well-maintained PHP environment alongside more up-to-date web software. When making your decision, don’t just consider the version: the website’s code, the status of any plugins and the range of functions enabled on the server are also important factors. If a function is failing, first check its requirements and the log entries.
In cPanel, use the PHP settings available on your hosting account, then check that the change applies to the website in question. After making the change, test the public part of the site and the administrative functions. For dynamic websites, also check forms, file uploads and background processes.
On the cPanel home page, use the search bar to find a menu item related to PHP. The names and locations of the screens that appear depend on your hosting settings. If you manage multiple websites, do not assume that a single setting applies to all of them in the same way. Check the description of the selected menu item and the domain details displayed before making any changes.
Take stock of your website’s engine, plugins and custom code. Test any features that use external modules or data processing separately. If you have a test environment, try out the website’s key functions there before making any changes in the live environment. In the case of bespoke development, error messages and test results together indicate which sections of code need to be fixed.
]]>When renting a VPS, most people compare the price, RAM and storage capacity, yet the type of processor used in the server is at least as important. It is no coincidence that more and more providers are building their servers around AMD Epyc processors, and an increasing number of people are specifically looking for this type of virtual server.
The plan descriptions often feature these three elements together: AMD Epyc processors, KVM virtualisation and NVMe SSD storage. Each of these is important in its own right.
AMD’s server processor range, designed specifically for data centres, virtualised infrastructure and sustained, heavy workloads, is optimised for reliability, high computing capacity and scalability. In many respects, it differs from processors intended for desktop computers: it offers multiple cores, a large cache and numerous memory channels, enabling a single physical server to host many virtual machines with consistent performance.
KVM (Kernel-based Virtual Machine) is a solution built into the Linux kernel, based on the processor’s hardware virtualisation capabilities (AMD-V). It provides full virtualisation: every VPS is a separate virtual machine with its own virtual processor, memory, disk and kernel. This is why a KVM VPS behaves like a dedicated server: you can run any operating system and software on it, including those that would not work on a container-based VPS.
A fast VPS is built on fast storage. NVMe SSDs connect to the PCIe bus and are many times faster than SATA SSDs, particularly when handling numerous parallel, small write and read operations. This results in noticeably faster performance for databases and websites that handle large numbers of small files.
A VPS runs on a physical server alongside many other virtual machines. Each VPS is allocated its own virtual processor cores (vCPUs), which are served by the physical cores and threads of the host machine. The host machine’s processor determines how much computing capacity is allocated to the virtual machines at any one time, and how they behave when multiple virtual machines are placing a load on the server.
On an older, lower-core-count host machine, virtual machines start competing for processor time sooner, and during peak periods this manifests as a slowdown on your server too. The Epyc architecture delivers performance at VPS level that previously required a dedicated server.
The Epyc family comprises several generations and many models, but their key features are common to all.
Epyc processors offer a huge number of cores in a single socket: the larger models feature 96 or 128 cores, whilst the flagship model of the latest, fifth-generation (Zen 5-based, 9005 series) family boasts 192 cores and 384 threads. The more physical cores available, the more virtual machines can run simultaneously without competing for processor time. High-load websites, databases and web applications benefit directly from this: response times remain more predictable even at peak times.
Most models feature several hundred megabytes of L3 cache, with versions featuring 3D V-Cache technology offering even more. Thanks to the large cache, the processor needs to access the slower memory less frequently, which is particularly noticeable when working with databases and web applications that handle a large number of small requests.
No matter how fast a processor is, it’s of little use if it can’t retrieve data from memory quickly enough. The fourth- and fifth-generation Epyc processors handle 12 DDR5 memory channels per socket, allowing more data to flow between the processor and memory simultaneously. This is particularly important for memory-intensive applications, such as large databases and caching systems (Redis, Memcached).
A single Epyc processor provides 128 PCIe 5.0 lanes, and up to 160 in a dual-processor system. NVMe SSDs and network cards are connected to these, enabling the server to handle multiple high-speed storage devices and high-bandwidth networks simultaneously without any bottlenecks. In a VPS, storage and network speeds are at least as important as the processor’s speed: an online shop or a database performs many small read and write operations.
Epyc is based on the x86-64 architecture, so it can run all common server operating systems: Linux distributions (Ubuntu, Debian, AlmaLinux, Rocky Linux) and Windows Server alike.
The essence of a VPS is that several virtual machines run on a single physical server, each isolated from the others. The hardware virtualisation support (AMD-V) in Epyc processors is designed for this purpose, whilst KVM, built on top of this, provides each VPS with its own kernel and its own resources.
The combination of multiple cores, multiple memory channels and fast I/O means that a host machine running Epyc can run many virtual machines quickly and stably alongside one another. This means your VPS is less affected if another virtual machine running on the same host machine is currently under heavy load. As your project grows, upgrading to a larger plan will increase your processor, memory and storage capacity, and on multi-core servers, the provider can maintain sufficient reserves to accommodate this.
When it comes to VPS rental, most people think of firewalls, strong passwords and updates when it comes to security. These are indeed the most important factors, but modern server processors also offer an additional layer of protection, and Epyc is one of the most sophisticated solutions in this regard.
Traditional security measures, such as TLS encryption, VPNs and firewalls, protect against attacks coming over the network and encrypt data whilst it is being stored and transmitted. However, they do not address what happens to the data whilst the virtual machine is processing it, meaning it remains unencrypted in memory.
In a traditional virtualised environment, the host machine (the hypervisor) technically has access to the memory of the virtual machines running on it. The purpose of hardware-based security features is to restrict this access at the processor level: the virtual machine’s data remains encrypted even if someone attempts to read it from the host machine.
Epyc processors feature security functions collectively known as AMD Infinity Guard. SME (Secure Memory Encryption) encrypts the entire system memory. SEV (Secure Encrypted Virtualisation) goes a step further: it encrypts the memory of virtual machines, using a separate key for each one. The keys are generated and managed by the security processor (AMD Secure Processor) built into the processor, ensuring that they do not enter the area accessible to software or the host operating system.
Encryption takes place in the memory controller whilst the system is running, so applications do not need to be rewritten to support it; however, the operating system running within the virtual machine must support it.
SEV-ES (Encrypted State) encrypts not only the memory but also the contents of the virtual machine’s processor registers when control is transferred from the virtual machine to the hypervisor. This means that even a compromised hypervisor cannot read sensitive data, such as keys, from the registers.
SEV-SNP (Secure Nested Paging) is the most advanced level. In addition to encryption, it prevents the hypervisor from silently modifying, swapping or replaying the virtual machine’s memory, and enables attestation: the owner of the virtual machine can verify that their machine has indeed booted in a protected environment with the expected software. The virtual machines offered by major cloud providers under the name ‘confidential computing’ are typically based on this; in 2020, Google also built its first such Confidential VMs with encrypted memory on Epyc processors.
Just because a server is powered by an Epyc processor does not mean that the VPSs running on it automatically benefit from encrypted memory. To use SEV, the provider must enable the feature and support it within the virtualisation system, whilst the virtual machine must boot with an operating system and firmware configured for this purpose. Encryption comes at a performance cost and may also restrict certain functions (such as live migration or certain backup methods).
If your work requires this level of protection (for example, due to the handling of strictly regulated data), ask the provider about this before signing up, and request confirmation that SEV-SNP is actually running on your virtual machine. Where the provider utilises these features, data used whilst the system is running is also encrypted, and the virtual machines of multiple customers on a single host are more effectively isolated from one another.
No, there is no such thing as complete security in IT. In recent years, researchers have demonstrated several attacks targeting various versions of SEV; AMD has addressed these with firmware and microcode updates. The effectiveness of hardware-based protection therefore also depends on how up-to-date the server’s firmware is, and how carefully the service provider operates the system.
In reality, most VPS servers are not hacked via the hypervisor, but through the software running on the virtual machine: via an outdated CMS, a weak SSH password or a service left open. Hardware-based encryption does not protect against these. The most important steps remain:
A large proportion of server operating costs is accounted for by electricity and cooling. Epyc processors deliver a high level of performance per watt, meaning a data centre can carry out the same work with fewer servers, less space and less cooling. This directly benefits the provider, but in the longer term it is also reflected in prices: VPS providers can offer more resources for the same amount of money, whilst lower energy consumption is also better for the environment.
When choosing a VPS, we rarely think about it, but the future-proof nature of the underlying platform also matters: it’s worth building on a service that will still be competitive in a few years’ time and which the provider can continue to develop.
The choices made by major cloud service providers serve as a good guide in the server market, as they purchase in huge volumes following thorough assessments. Amazon Web Services, Microsoft Azure, Google Cloud and Oracle Cloud all offer AMD Epyc-based virtual machines, in general-purpose, memory-optimised and high-performance computing (HPC) variants. According to AMD, more than a thousand Epyc-based instance types are already available from the major cloud providers.
One advantage of such a widely used platform is that software, operating systems and virtualisation tools all support it well, and bugs and security vulnerabilities are fixed quickly because they affect a huge number of users.
AMD releases a new generation of Epyc processors every few years, each with more cores, greater efficiency and faster memory. The fourth and fifth generations use the same SP5 socket, so service providers can upgrade their machines without having to replace the motherboard, and AMD has also announced the next generation (Zen 6, ‘Venice’). An Epyc-based service is therefore not a technological dead end: the service provider can gradually switch to newer hardware, whilst your VPS continues to operate as normal.
Like all VPS services, this one also provides dedicated, guaranteed resources (CPU, RAM and storage) at a much lower cost than a dedicated server. Here are a few typical scenarios where it’s worth it.
An online shop must remain fast even when many people are shopping at the same time and the product and order database is constantly growing. With shared hosting, the resource limitations of the hosting eventually become a constraint: the site slows down during peak periods, and a slow site means lost customers.
On a VPS, your online shop runs on its own dedicated, guaranteed resources, and you can tailor the web server, PHP, database and cache to suit your specific needs. A typical sign that it’s time to switch: your online shop’s traffic has increased, your hosting plan’s resource limits are regularly being reached, and the site’s slowness is now affecting sales.
A VPS provides full root access, so you can install any development tools, databases or runtime environments on it – something that isn’t possible on a shared hosting plan. It’s ideal for:
If the staging and production environments run on the same type of VPS, the test results will provide a much better indication of how the system will behave in production.
With larger MySQL, MariaDB or PostgreSQL databases, both the processor and the storage have to work hard. A large cache, multiple memory channels and NVMe storage help with the many small read and write operations.
Training and running large language models requires a GPU, and a standard VPS is not suitable for this. However, a great many AI and data processing tasks run on the CPU, and a multi-core VPS provides a good foundation for these:
It’s not just for businesses. A VPS is a good choice if you want to run several of your own projects in one place, under your own domains; if you want to run your own cloud storage (such as Nextcloud), a VPN, a mail server or a game server; if you want to learn Linux and server administration in a real-world environment; or if you want to try out software that wouldn’t run on a shared hosting plan.
For a hobby project, even the smaller plan is often enough: with us, the AMD VPS 1 offers 1 vCPU, 1 GB of RAM and 10 GB of NVMe SSD storage for a monthly fee of €4.62 + VAT.
The AMD Epyc VPS is a good choice in many situations, but it isn’t always necessary:
With a VPS, you have the freedom, but you also bear the responsibility: you have root access, which means you’re responsible for updates, the firewall and security settings. If you’d rather not do this yourself, our managed VPS service will take care of the server for you.
The processor is important, but its benefits only really come into their own if the other components can keep up with it. When looking at a good VPS deal, you should also check:
The concept of a VPS remains the same: a dedicated virtual machine running on a physical server. The difference lies in the host machine’s processor, which affects performance, the handling of concurrent workloads and the available security features.
This is because the host machine can run multiple virtual machines without them competing for processor time. The performance of your own VPS’s vCPUs is therefore more predictable.
No. The provider must enable it, and the guest operating system must also support it. If you need this, please enquire before signing up.
Both are state-of-the-art server processor families. Epyc generally offers more cores, more memory channels and more PCIe lanes, making it powerful for parallel, virtualised workloads. Certain Xeon models may be more advantageous for specific tasks (such as those utilising built-in AI accelerators). For a general-purpose VPS, the resources included in the VPS plan, the storage and the reliability of the provider matter more than the brand of the processor.
With its multiple cores, large cache, numerous memory channels, fast I/O and architecture designed for virtualisation, the AMD Epyc provides a stable, predictable and highly scalable foundation for VPSs, whilst its hardware-based security features offer stronger isolation wherever the provider utilises them. Our AMD Epyc KVM VPS plans are available with a 3.8 GHz processor, PCIe NVMe SSD storage, a 2 Gbps connection, unlimited traffic, daily backups and DDoS protection, ranging from 1 vCPU to 16 vCPUs and from 1 GB to 32 GB of memory, from €4.62 per month plus VAT.
]]>The setup may seem complicated at first, as it requires server-side configuration, appropriate network access and client settings. This article explains what a VPN is used for, how to set up home or remote access, and how to export the OpenVPN configuration to the connecting device.
We’ll walk you through the necessary network settings, port forwarding and the role of keys and certificates. We’ll also discuss how to choose between OpenVPN and WireGuard, and what factors affect connection speed. These steps will help you set up access that suits your home network and your intended use.
When using PPPoE passthrough, the functioning of the internet connection may depend on the router’s settings. According to a forum reply, by connecting your own router to the Sagemcom ETH1 port and using PPPoE passthrough, your own router can establish the PPPoE connection. When using PPPoE passthrough, the set-top box can operate independently of your own router when connected to one of the provider’s router’s LAN ports. This means that your own router’s internet connection and the set-top box’s connection can be established via separate paths.
The ISP’s router is usually accessible via a direct LAN connection, but from the router behind it only if you set up a static route on it and the device supports this. During the check, it examines the accessibility of the ISP’s router, the address displayed on the router and the ping result separately. Compare the address displayed on the router with the public IP address shown on an external testing site. The router may block ping requests even if the ISP’s network does not filter them; therefore, a failed ping does not in itself prove that the ISP’s network is blocking the requests.
From home, the VPN server can be accessed via the local network, but when connecting remotely, you’ll need to connect via the internet. For a home OpenVPN server, forward the port you’re using to the server’s static internal IP address, then use dynamic DNS to assign a permanent name to the changing public IP address.
redirect-gateway def1 setting in the OpenVPN configuration. In this case, the overall route will also depend on the server’s upload speed.wg genkey command to generate the private key, then use the wg pubkey command to generate the public key. The private key must remain on the device in question and must not be logged or stored in a shared file. Add the public key to the other party’s peer settings.AllowedIPs field specifies which traffic is permitted to pass through the virtual private network tunnel.If the OpenVPN server is running on a NAS or router, AES-256 can be used as an example when reviewing the encryption settings. The client-side profile must match the server’s settings, so please check the specified connection and authentication details before connecting. When creating a Windows VPN profile, select the VPN connection type based on the type used by your organisation or VPN service. You can use a username and password, a one-time password, a certificate or a smart card for authentication. Select the authentication method that is actually supported by the server and the profile in question; this will help prevent the connection from failing due to configuration discrepancies. Test the profile on the actual client and verify the connection whilst accessing the desired network resources.
The OpenVPN configuration shown here uses the 192.168.2.0 255.255.255.0 network for VPN clients. It is advisable to check this address range alongside the client settings to ensure that the assigned addresses do not conflict with the internal networks you wish to access. The server sets the keepalive parameter to 10 120: the connection is checked at 10-second intervals, and the timeout is 120 seconds. During testing, check whether the client can reach the server again after the connection is lost, and whether the required routes are still functioning. If you make any changes to the configuration, check that the values match on both the server and client sides, then repeat the test. This ensures that the chosen OpenVPN configuration not only starts up but also provides the intended access.
aWh’s web hosting may be the right choice if you wish to run a website alongside a VPN running on a Linux VPS. The VPN server and the web hosting serve separate purposes: the VPN provides secure remote network access, whilst the web hosting is used to host the website. This means that setting up your own VPN server can be kept separate from the operation of your web content.
If your main aim is still to run WireGuard, when choosing a server, take into account the Linux environment, the necessary network settings and the planned client connections. aWh Web Hosting is available for website hosting. To find out more about our services, please visit awh.hu.
Once you have set up your own VPN server, establish a simple maintenance routine: keep the system up to date and revoke access for devices that are no longer in use. Also, make a record of which users and network resources can be accessed remotely. This way, the configuration remains clear even when you connect a new computer or mobile phone.
If you need a Linux-based server environment to run a VPN, aWh’s KVM VPS service may be of interest. Web hosting is used to run websites, whilst domain registration is for using your own web address. These serve different purposes, so please choose the option that best suits your specific technical requirements.
If you’d like to explore the available options, ask aWh for help. With a well-planned next step, you can confidently continue to build your own network environment.
With a VPN, you can access designated resources on your home or work network remotely. It’s worth using if, for example, you need to access an internal business application or your own network device whilst on the move. You can specify in advance which users and devices are allowed access, so the connection does not automatically extend to the entire network.
A VPN is a network connection through which traffic can flow between a device and a remote endpoint. It works differently from remote desktop access: a VPN provides a network connection, whilst remote desktop displays the user interface of another computer. You can also access various local services via a VPN, provided that routing and permissions allow it.
Your home router can serve as a suitable endpoint if you wish to access your own home devices from the internet. With a VPS gateway, you can run the VPN on a separate server, meaning access to it does not depend on whether your home router is switched on. The two solutions are not necessarily mutually exclusive: if you also wish to access your home network via the VPS, you will need to plan the route between the two networks.
A home server requires a computer or router on which VPN software can run continuously and which has a stable network connection. Remote data transfer may be limited by your home internet upload capacity, particularly when accessing large files. In the case of a VPS, select the server’s resources based on concurrent traffic and the encryption load. The network card and routing also affect performance.
Select a supported Linux environment, then log in with administrator privileges. Once you have installed and configured WireGuard, start the connection using the command wg-quick up wg0. You can view the status of the interface and peers using the command wg show. If everything is working correctly, set the service to start automatically, then test it again after a reboot.
In the client application, check that you are connected to the correct server and that you are only using the necessary network routes. With WireGuard, the output of wg show on the server shows the latest handshakes and traffic for peers. When setting up your phone, do not display the configuration QR code in public places. In the event of a connection error, first check the client’s status, then examine the server log.
If you’re looking for a solution that’s quick to learn, it’s understandable that Wix seems like a convenient choice. WordPress is an open-source system, so the structure and functionality of your site can be customised in a variety of ways, but you’ll also need to take care of hosting, updates and backups.
In this comparison, we’ll show you which platform is easier to use for beginners, how their customisability differs, and when greater freedom offers a real advantage. We’ll also look at the factors that influence your choice and what to bear in mind if you’re moving your website from Wix to WordPress. This will make it easier for you to decide which system suits your level of experience and your plans.
The appearance and functionality of a company’s website are determined by the chosen template, the applications used and the scope for subsequent modifications. There are thousands of free and paid templates available for WordPress. On Wix, you select a template in the editor and then customise the page elements within it.
A Wix template is a good starting point if, for example, you’re looking for a ready-made layout for a services page, an introductory website or a contact page. In the visual editor, you can edit the text, images and the positioning of page elements. This requires little technical preparation, but you may encounter more restrictions if you wish to make changes beyond the template’s structure.
Amongst WordPress themes, you can find solutions for everything from simple company landing pages to more complex content structures. The theme determines the basic look of the site, whilst plugins can add new features. For example, you can choose a separate plugin for a contact form or for content management tasks. The wide range of options gives you greater freedom, but it is also up to you to choose plugins from reputable sources that are regularly maintained.
WordPress is an open-source system, so developers can customise not only the template but also the way the site works. This can be important if the company website is later expanded to include new content sections, custom forms or features tailored to a specific workflow. With Wix, you can work with the built-in editing and app features, which may offer simpler handling but can limit the range of custom solutions available.
Choose plugins for specific purposes; do not install a new one for every feature you can think of. The vast majority of security vulnerabilities discovered in WordPress websites are found in plugins, not in the core WordPress system. Check whether you really need a particular plugin, then keep your website’s components up to date. Having lots of plugins does not in itself guarantee better business results.
| Option | Customisation | Expansion | Typical task |
|---|---|---|---|
| Wix template | Visual editing | With applications | A company website that can be set up quickly |
| WordPress template | Setting and changing the theme | With plugins | Varied content structure |
| WordPress plugin | Focuses on one feature | Adds further functionality | Forms or content management |
| Custom development | Can be tailored to your needs | Through development work | Specialised business processes |
Choose Wix if ready-made templates and simple visual editing are your main priorities. WordPress may be a better option if you want to use your own templates, plugins or developer customisations.
You can choose from thousands of free and paid templates for WordPress websites. First, decide what page sections you need, what look suits your business, and what changes you expect to make. Look for a solution that organises your current content well, but doesn’t force you to use unnecessary elements. A different template may be suitable for a simple introductory page than for a complex website where a wide variety of information needs to be presented clearly. As well as the visual design, consider how easily you can edit the necessary sections yourself.
Price alone does not determine whether a theme is suitable. Consider whether it fits the purpose of your website and whether you can easily create the desired structure within it. If you only need to make minor adjustments to the ready-made layout, ease of editing may be the deciding factor. If specific requirements arise later on, consider whether you would prefer to address them through the template’s settings, customisation or further development. The choice is therefore not just about the appearance, but also about how you will work with the site in the future.
Switching from Wix to WordPress requires more preparation than simply changing a template. You need to review the site’s content, images, links and features separately, and then set them up in the new system. Missing content, broken links or a different site structure can pose a risk.
On the Wix website builder platform, editing and design are integrated into a single system. With WordPress, the website’s design is determined by the chosen template, its content by the admin panel, and its functionality by various settings. Whilst this can offer greater flexibility, it also involves more tasks when it comes to maintaining the site. For example, a bespoke design created for a Wix site cannot necessarily be transferred to a WordPress template without modification.
Before making the switch, draw up an inventory of your content and note which elements need to be retained on the new website. Make a list of the homepage, service pages, contact form, images and menu links. For a company website, service descriptions and contact details may be more important than an old, disused subpage. This preparation will help you determine what needs to be recreated.
The practical steps involved in the migration build on one another:
A WordPress site requires a domain name and hosting. You retain control of the domain if you have registered it in your own name. The files and database of a WordPress website are under the owner’s control and can be moved to another hosting provider. This differs from using Wix, where the site operates within the platform’s system. When planning the migration, you should therefore treat the domain settings and the content of the new WordPress system separately.
Within WordPress, changing your theme can also alter the layout, menus and the appearance of page elements. Before choosing a new theme, compare the key pages of your old website with the examples provided by the new theme. The Wix website builder interface is based on quick, visual editing, whereas WordPress handles the theme and content separately. It is worth switching if you are prepared to take on more conscious management of content and functionality in exchange for greater freedom.
When planning your switch, bear in mind the costs as well as the technical tasks involved. The initial costs of a WordPress website may include the domain, hosting and the web designer’s fees. Tailor these to your own needs and the planned design of the site; don’t just focus on the considerations that arise when choosing a template. If you are using a professional, clarify in advance which content you expect to be transferred and which features you want to be developed. This way, the cost estimate can reflect the work that is actually required.
It is worth comparing the costs of a subscription-based website builder and WordPress over different timeframes. Compare this figure with the initial costs of WordPress, and consider how much time you can devote to managing and maintaining the system. When making your decision, don’t just consider the initial set-up: factor in content updates, future modifications and any external assistance that may be required. The choice will be the right fit for your website if, in addition to the financial commitment, the method of management also suits the way your business operates.
Wix requires less technical maintenance on your part, as the platform manages the underlying system. With WordPress, you need to keep an eye on updates, plugins and backups. In both cases, correct configuration and regular checks are important.
Wix’s plans combine the editor, hosting and selected features on a single platform. With WordPress, you need a domain and hosting, whilst themes and plugins provide additional options. One system is therefore more centralised, whilst the other is made up of several separate components.
When comparing plans, check which tasks and features each solution covers. For a business website, for example, it may be important to have a contact form, a custom domain or an online shop. Check how you can manage these via the control panel, and what settings you’ll need for day-to-day use.
An increase in visitor numbers, the expansion of content or the launch of an online shop can alter a website’s technical requirements. Think about how you would add new service pages or product categories right from the design stage. With Wix, the editor interface and subscription tier determine the features available. With WordPress, the hosting, theme and selected plugins together shape the system.
You should also take into account the time required for maintenance. Wix manages the platform’s operation centrally, whereas with WordPress, you or a contracted specialist takes care of routine tasks. A simple introductory page may require less maintenance than an online shop that is updated regularly. Before updating, make a backup, and afterwards check the site’s key functions.
When making your decision, don’t just consider the name of the plan or the number of resources available. Compare the management process, the maintenance required of you and the possibilities for future expansion. Make a list of the initial features required for your company’s website, then assign responsibility for configurations and updates. This will make it easier to choose a system that suits your day-to-day operations.
To run a WordPress website, you need your own domain and hosting. The domain is yours if you have registered it in your own name. With WordPress, the website’s files and database are under your control and can be moved to another hosting provider. With Wix, the site runs on the platform’s system, so to perform the migration, you need to transfer the content separately and carry out the new set-up.
When switching from Wix to WordPress, you’ll need to transfer text and images separately. Save your site’s content and media files, then upload them to the relevant WordPress pages and the media library. Next, reconfigure the menus, forms and other features. If you’re using WooCommerce, make sure to organise your product data and related content in the new system as well.
Google rankings and URLs are not transferred automatically. Where possible, retain the old addresses and set up redirects for any URLs that have changed. Before migration, make a note of the URLs of your Wix pages, then check the landing pages, internal links and redirects on the new website.
Before the migration, draw up a checklist of the content to be transferred:
When choosing a hosting plan, take into account your resource requirements, the storage you need and the expected traffic on your website. A company’s landing page has different requirements to a WooCommerce online shop, which also manages product pages and orders. When switching hosting providers, you must transfer the files and the database together, then check that the content and functions are displayed correctly.
Updating WordPress, themes and plugins requires attention from a security perspective. Before updating, make a backup so that you can restore the previous state in the event of an error. Managing your domain and hosting separately gives you greater flexibility, but the operational settings are spread across multiple locations. The cPanel hosting control panel allows you to manage tasks related to your hosting via a web interface.
Treat domain registration and hosting as separate decisions: domain ownership and the storage of website files serve different purposes. The migration will be straightforward if you compare the old and new URLs in advance, organise your images, and then test the main functions of the new WordPress site separately. The switch is therefore not just about designing the new look, but also about the orderly transfer of content, infrastructure and security settings.
The main difference between Wix and WordPress is their operating model: Wix is a website builder, whilst WordPress is a content management system. This determines how you can edit pages, manage content and expand your company website in the future.
With Wix’s visual website builder, you can manage both editing and website operation in one place. You can place ready-made elements on your pages, edit the text and see the changes immediately. This makes it easy to edit a personal website, for example, and means you don’t need to worry so much about the technical details of the system.
Wix can be convenient if you want to manage your website from a single, centralised interface. The visual editor is useful, for example, for updating the text or images on a services page. The add-ons and settings are tailored to the platform’s capabilities, so customising its functionality may be more limited.
WordPress is an open-source content management system. You can edit the content via the admin panel, whilst the layout is determined by the theme. You can extend its functionality with plugins. Compared to Wix, you have more control over aspects such as hosting, updates and backups.
This structure can be useful if your company’s website is expanded over time with new content or more complex features. For example, you could add new subpages to a services page, and later add a blog. WordPress gives you greater control over how the site works, but you or your developer will need to coordinate the theme and plugins.
WordPress.com and WordPress.org offer different ways of using the platform. WordPress.com provides WordPress as a hosted service, whilst the WordPress.org software can be installed on your own hosting account. The latter gives you greater freedom in choosing your hosting provider and technical settings.
When choosing WordPress over Wix, first decide which version best suits your needs. A centrally managed environment may offer a simpler start, whilst WordPress running on your own hosting provides greater control. For a business website, you should also consider who will be responsible for updates and maintenance.
WordPress treats posts and pages as separate content types. A business, for example, can publish blog posts on a regular basis alongside static pages showcasing its services. Posts can be organised into categories, allowing readers to browse content by topic. This structure is well suited to websites that are updated frequently.
You can also create a blog on Wix, but editing and expansion are limited to the platform’s built-in tools. With WordPress, you can tailor content management to your chosen theme and plugins. If you’re planning to have multiple authors, regular news updates or new content categories, consider which system is better suited to your day-to-day work. Key factors in this decision include the editing process, management requirements and the potential for future expansion.
aWh provides web hosting on which you can install and run your WordPress site. When switching from Wix, ensure you have suitable hosting and configure your domain to point to the new site. It is advisable to manage your domain registration separately from the operation of your website.
If you also need business email addresses for your company website, aWh offers email hosting too. You can choose between web hosting, KVM VPS or domain registration, depending on your needs. The right solution depends on whether you want to run a WordPress site, register your own domain or use email.
You can find further information about aWh’s web hosting solutions on the web hosting page. Visit awh.hu to browse the options.
Before choosing a system, decide who will handle the website’s daily updates, technical settings and content additions. If you’re switching from Wix to WordPress, draw up a plan for transferring the site structure, domain and hosting. This way, you’ll be able to see right from the start which tasks you can carry out yourself and which ones might require technical assistance.
aWh’s solutions for web hosting, KVM VPS and domain registration are tailored to a range of operational requirements. When making your decision, take into account the size of your website, its planned features and the capacity available for managing it. If you’d like to explore which options are best suited to your WordPress site, ask the aWh team for advice. A well-planned start can provide a solid foundation for the further development of your company’s website.
Wix is generally easier to learn to use, whilst WordPress requires more configuration and independent decision-making. If you simply want to change your opening hours or the description of a service, Wix’s visual editor can be convenient. When switching from Wix to WordPress, bear in mind that, as well as editing content, you will also need to manage updates and plugins, or ensure that someone else handles these for you.
Loading speed on both platforms is influenced by the website’s structure and content. Large image files, numerous external elements and unnecessary plugins can slow the site down. With proper optimisation, a WordPress website can load in less than two seconds. To ensure fast performance, compress your images, keep the page uncluttered and check it regularly on mobile devices too.
To use WordPress, you’ll need a domain and hosting suitable for running WordPress. Choose your domain extension based on your website’s target audience and name. For a Hungarian business, a .hu domain may also be suitable if it fits your brand and audience. When choosing your hosting, take into account your website’s content, expected traffic and features. The resource requirements of an online shop may differ from those of a landing page.
The annual running costs of a WordPress-based website consist of the domain name fee, the cost of a reliable hosting service, and the cost of premium plugins or themes. Whilst Wix operates on a fixed monthly fee system, with WordPress you can choose more cost-effective or higher-performance providers from aWh’s range, allowing you to tailor your expenditure more precisely to your actual needs.
]]>If you run a website, an error message may not provide much guidance at first, but it is an important indicator: the problem may be related to the request or to the server’s operation. Noting the exact error code and the page affected will help narrow down the possible causes.
The article explains the meaning of common HTTP error codes, the possible causes of 500 errors and the key points to consider when resolving them. You can also find out how to identify broken links, when it is advisable to redirect a deleted page, and how a useful 404 page can help guide visitors to other content.
A 404 response code means that the server cannot find the requested document. When interpreting website error messages, the website therefore first examines the relevant URL and its HTTP response code. Persistent 500 errors indicate a different kind of problem: the server is unable to fulfil the request, which can impair the user experience and the site’s availability.
The NET::ERR_CERT_DATE_INVALID browser error indicates that the certificate’s expiry date is incorrect, or that the computer’s date and time are inaccurate. Check both, then verify that the website’s certificate is valid.
In your Google Search Console reports, locate the affected pages and the URLs returning a 404 error. Then open the relevant URL and check whether the error is caused by a typo, a changed path or deleted content. Also check your internal links: an old menu item or article link may direct visitors to a page that no longer exists.
SEO tools crawl a website’s links and response codes. Screaming Frog SEO Spider, Ahrefs Site Audit and SEMrush Site Audit, for example, can also identify URLs returning a 500 error. Compare the results URL by URL with the data from Search Console, then either fix the broken internal link or set up a 301 redirect if there is a relevant replacement page.
A 500 error on a visitor’s page can interrupt their browsing experience, for example when opening an article or a form. If the problem persists, Google may temporarily or permanently remove the affected pages from its index. Therefore, when rectifying the issue, prioritise important pages and those with many internal links pointing to them.
If you’re experiencing CMS or PHP issues, check for updates, plugins and the server log. An out-of-date CMS or an incompatible plugin can cause a 500 error. In the case of WordPress, deactivate all plugins and then reactivate them one by one; this will help you identify the element causing the error. PHP version 7.2 or earlier is considered outdated; in such environments, it is recommended to upgrade to PHP version 8.0 or 8.1. For Apache, the /var/log/apache2/error.log file, and for Nginx, the /var/log/nginx/error.log file, can help identify the cause of the error.
Check the links on your website on a monthly basis to ensure that broken links do not go unnoticed. Contact your hosting provider if you haven’t modified any content, but an important URL continues to return a 404 error. It is advisable to seek assistance from your hosting provider if several pages are returning a 500 error, or if the server logs indicate configuration, database or resource issues.
By re-enabling your WordPress plugins one by one, you can identify which one is causing the error. Check the page after each re-enable; this will allow you to narrow down the possible causes step by step and tailor the fix to the problematic plugin.
Your custom 404 page appears when a visitor tries to access a URL for which no document is available. In the case of a hard 404 error, the server sends a 404 response code and the website’s error page is displayed in the browser. This page should do more than simply state that the content cannot be found: it should help the visitor to continue browsing.
A well-designed 404 page briefly explains the error and then offers specific options for what to do next. Include a search box or recommended content and products on the page. For example, if someone mistypes the title of an older blog post, the search function can help them find the updated version of the post. A link back to the homepage can also be useful, but it shouldn’t be the only option provided.
Do not automatically redirect non-existent URLs to the homepage. In such cases, the server may send a 200 status code, whilst the visitor sees an error page. This results in a ‘soft 404’ error, as the status code indicates a successful load, but the content cannot be found. A page that has actually been deleted should receive a 404 response, or be redirected to an appropriate replacement page, if one exists.
Assess the performance of your 404 page based on the visitor’s journey. 36 per cent of visitors landing on a non-existent page click the browser’s back button. Therefore, ensure the search bar, main navigation and key categories are clearly visible. For example, on an online shop’s error page, a recommendation for the relevant product category may be more useful than a general link to the homepage.
The design of the error page should match the rest of the website. Retain the header, navigation and branding elements so that visitors know they are still on the same website. The error message should be easy to understand, and the search box should accept product names, article titles or topics. Test the page by opening a non-existent URL and check the response code as well.
The title and description that appear in search results, as well as the H1 heading visible on the page, each serve a specific purpose. Every page should have a unique title and meta description, whilst the H1 heading should clearly state the page’s topic. On a 404 page, for example, the H1 heading might state that the page being searched for cannot be found, whilst the description might suggest using a search engine or the site’s navigation.
If an internal link still points to an old address, correct the link on the original page. This way, visitors won’t keep encountering the same error, and the 404 page will only appear for addresses that have genuinely been removed or were entered incorrectly.
A 301 redirect can be used when there is a relevant replacement for a deleted page. In this case, the browser is taken to the new address, and the server indicates that the redirect is permanent. This is different from the 302 HTTP status code, which indicates a temporary redirect. The 3xx group of HTTP status codes generally indicates a redirect.
First, find out why the original link isn’t working. Open the URL in question, then check whether the error is caused by a typo, a changed address or deleted content. If only the page’s address has changed, update the internal link to the new address. If a link to an external website is no longer valid, find a working destination page on the same topic.
When redirecting, the new page must offer a relevant alternative. For example, the product page for a discontinued product could be redirected to a genuinely related product category. Do not automatically redirect every incorrect URL to the homepage. If the content of the new destination does not match that of the old page, the visitor will not find what they are looking for.
Assign the redirect rule to the relevant route, then check the result. Open the old URL in your browser and check that the correct new page loads. Then test the new address directly as well. If it redirects to yet another address, review the rules and remove any unnecessary steps.
When fixing broken links, don’t just change the redirect rule. Find the page containing the old link and update the destination URL. Check the navigation, footer, articles and sitemap as well. This ensures that visitors and web crawlers are taken directly to the correct page.
Even after reorganising your content, be sure to check your links. Changing a menu item can leave broken links on several subpages. Once you’ve made the correction, review the affected pages, the response code and whether the content of the new destination matches the old one. This will help you distinguish between a broken link and a problem caused by a deleted page.
When modifying redirect rules, check the configuration carefully and do not automatically assume that an incorrect response is due to a content issue. An incorrect setting or typo in a faulty .htaccess file can cause a 500 error. Therefore, after saving the rule, check the relevant URL, and if an error appears, review the newly modified setting. It is worth keeping your rules organised so that a specific redirect can be easily identified. During testing, also ensure that the correction does not affect the behaviour of other routes. If you have modified several rules, check the affected URLs individually; this makes it easier to determine which setting requires further correction.
It is not recommended to automatically redirect URLs pointing to a 404 error page to the homepage, as this can cause a ‘soft 404’ error. First, examine such a URL based on its content and purpose. If there is no relevant, related replacement page, do not set a destination that does not provide an answer to what the visitor was looking for. After making the correction, try accessing the old URL and check that the result matches the actual state of the content. Review the rules from time to time, particularly when you delete or reorganise pages. This will prevent a previously correct setting from later leading to a misleading destination page.
The HTTP status code indicates how the server handled the browser’s request. They can be categorised into five groups based on their first digit: 1xx, 2xx, 3xx, 4xx and 5xx. When troubleshooting, first check which code is displayed. Then check whether the problem affects a single URL or multiple pages.
1xx codes are informational responses. An HTTP status code of 100 indicates that the client may proceed with the request. The HTTP status code 101 indicates a protocol switch. The HTTP status code 102 indicates that the server has received and is processing the request. These are not the same as a response indicating that a web page is ready.
2xx codes indicate a successful request, such as the 200 OK response. The 201 HTTP status code indicates that a resource has been created. The 202 HTTP status code indicates a request that has been accepted but not yet completed. The HTTP status code 204 indicates a successful request with no response message. The 205 response requests that the document view be reset, whilst 206 indicates partial content.
The 3xx group indicates a redirect. A 301 response indicates a permanent redirect, whilst a 302 HTTP status code indicates a temporary redirect. The 303 HTTP status code directs the user to a resource located at a different URL. When troubleshooting, check the destination address and the redirect chain. If one address redirects to several further addresses, the browser may eventually end up on the wrong page or be unable to load the content.
4xx codes indicate client-side errors, whilst 5xx codes indicate server-side errors. The 400 HTTP status code indicates an incorrect or invalid request. The 401 response indicates an authentication issue, whilst the 403 response indicates an authorisation issue. A 404 code means the document cannot be found, whilst a 410 code indicates that the resource has been permanently removed. A 500 code indicates an internal server error.
In the case of a 502 Bad Gateway, a 503 Service Unavailable or a 504 Gateway Timeout, some sort of server-side or inter-server problem is preventing the request from being fulfilled. A 502 error may indicate a communication fault, a 503 indicates that the service is temporarily unavailable, whilst a 504 indicates that the intermediary server did not receive a response in time.
Once you have interpreted the code, compare the affected URL with a working page. If only one URL is faulty, check its request and settings. If several pages return a 5xx error code, check the server logs and background processes. After rectifying the issue, request the same URL again and check whether the browser is now receiving the correct response.
Alongside the error code, make a note of the affected URL, the time the error occurred and any changes made prior to it. This information will help you distinguish between browser, website and server issues.
An HTTP status code in the 400 range indicates that the server is unable to process the request because it is incorrect or invalid. First, check the URL, then try opening the page again. If the error only occurs in one browser, clear the cookies for that particular website and try again.
When submitting the form, please check that you have filled in all the required fields correctly. If the same response appears in another browser, please note down the exact address and the action you took. This information will help the operator investigate how the system processed your request.
HTTP status code 401 indicates missing or invalid authentication details. Code 403 indicates that the account used for the request does not have permission to access the content in question. Therefore, for a 401 error, check your login details; for a 403 error, check the access rights assigned to the account.
If you manage the website, check the relevant user role and the site’s access settings. Do not include passwords or access tokens in error reports. If you share logs with the operator, remove any credentials and personal data from them first.
A DNS error indicates that the browser cannot resolve the domain name, whilst a connection error means that a connection to the server cannot be established. A timeout occurs when a response is not received in time. If only one website is affected, check the domain name and then try accessing it from a different network.
If several websites are unavailable, check your device’s network connection. If only your own domain isn’t loading, make a note of the exact error message displayed by your browser and the affected URL. These details will help you distinguish between a DNS resolution issue and a server outage.
Start troubleshooting by noting down the affected URL, the response code and the time the error occurred. Then try opening the page in a different browser, and check whether any other pages are also affected. If the error appeared after an update, examine the most recent change and test reverting it.
If you’re experiencing error code 500, check the server logs, the PHP code, the .htaccess settings and the database connection. Ensure that only authorised persons have access to the logs; do not disclose login details, session IDs or personal data. Redact sensitive sections before sharing, and do not send the entire log file if the relevant error details are sufficient.
If you need to identify the cause of the error by checking logs or settings, the hosting troubleshooting guides can help you choose which checks to carry out next. The error report sent to the provider should include the URL, the response code and the time, but should not contain any passwords or other confidential information.
aWh offers web hosting to those looking for hosting to run their websites. If recurring 503 or 500 errors are server-side, examining the logs and the affected URLs will help determine whether the issue lies with the website’s code, its configuration or the hosting environment. Based on this, the next troubleshooting step can be identified more precisely.
The right solution depends on the type of hosting and resources you need to run your website. Web hosting may be suitable for simpler websites, whilst KVM VPS is an option for environments requiring greater flexibility. Domain registration and Windows VPS are also available.
Take a look at aWh’s web hosting services, or get in touch with aWh.
Interpreting website error messages helps with decision-making when an operational routine is established based on experience. Make a note of when the error occurs, which functions it affects, and what changes preceded it. This way, the next investigation can be based on specific precedents rather than guesswork. As well as keeping updates and configuration changes up to date, ensure that your backups are also up to date so that you can restore the system to a previous state following any incorrect changes.
If the recurring error is server-side, choosing the right hosting environment may also be part of the solution. aWh offers web hosting, KVM VPS and domain registration, so you can find a solution to suit a range of website and operational requirements. The exact nature of the error and the website’s operational requirements will help you determine the next steps.
If you need support with the next step, ask the aWh team for help. With well-organised error logs, you too can keep your website running more reliably.
Error code 500 indicates an internal server error, so start by checking the server-side operations. If the error appeared after an update, revert to the last change and then check the page again. Make a note of the affected URL and the time the error occurred. If only one feature is faulty, such as the contact form, check its code and database connection first.
A 500 error can be caused by incorrect server settings, corrupted PHP code, database connection issues or a lack of resources. When using a CMS, incompatibility between an updated plugin and the existing system is also a possibility. Note whether the error began after an installation and whether it also affects the admin panel. Identifying the timing of the issue can help narrow down the changes to investigate.
Identify 404 pages by comparing the results obtained during website crawling with the landing pages visited by users. Also check the sitemap: it should not contain any URLs that no longer serve content. Then look for internal links pointing to the affected URL. Links appearing in the navigation bar, footer or frequently visited articles are particularly important.
Run a website crawl, then filter out the URLs returning a 500 status code. Group the results by path or page type: if several product pages follow the same pattern, a shared template or database query may be affected. Compare the errors with the crawl times using the dates in the server logs. This will help you distinguish between persistent errors and one-off response issues.
A 404 error can interrupt a visitor’s journey, for example, before they reach a product description or an important information page. If an internal link leads there, the website’s own navigation may also appear to be faulty. Search engine bots cannot access the content either, so check whether the page has actually been deleted. If the URL has simply changed, restore the link to the correct new page.
First, check the URL, as even a single typo can result in a ‘404 error’ message. If the content has been moved, update the old links or redirect the URL to the new page that is actually relevant. If the page has been permanently removed and there is no suitable replacement content, do not send the visitor to an unrelated page. The website’s search function can help visitors find relevant content.
Common error codes include 400, 401, 403, 404 and 500, as well as 502, 503 and 504. A 400 indicates an invalid request, a 401 requests authentication details, a 403 denies access, and a 404 means the content cannot be found. 5xx codes indicate a server-side issue. Alongside the exact code, make a note of which page it appeared on and following which action.
Please seek assistance if several pages consistently return a 5xx error, the log indicates a server or database error, or if you are unable to make changes to the settings due to insufficient permissions. In the case of a single broken link, the website operator can first correct the content or the URL. If the server’s response is incorrect, forward the relevant URL, the response code and the time of the error to your hosting provider.
]]>It’s understandable if you’re looking for a system that your colleagues can get to grips with quickly, and where emails and files are reliably accessible. The tools you choose must also support your existing workflows. The transition will go more smoothly if you plan the migration and training in advance.
This guide outlines the different types of solutions available and compares them in terms of business email, file storage and collaboration. You’ll learn about the key criteria for making a choice, followed by practical guidance on data migration and training staff. This will enable you to make a more informed decision about which system best suits the needs of your small business.
When choosing a collaboration system, treat email, documents and tasks separately. Google Workspace brings together Gmail, Drive, Docs and Meet in a single system. Microsoft 365 similarly offers a unified environment for using Outlook, OneDrive, Word and Teams. When choosing a Google Workspace alternative, therefore, don’t just look at the names of the applications. Existing file formats, access control and the number of interfaces your staff will need to learn are all important factors.
When managing documents, check the options for collaborative editing, version control and access levels. For example, a sales proposal can be edited by several people, whilst only designated staff members have access to the final file. OneDrive and SharePoint enable file sharing within the Microsoft ecosystem, whilst Nextcloud and ONLYOFFICE offer different deployment and operational options. A Google Workspace alternative is suitable if it covers not only the applications but also day-to-day editing tasks. Before making a decision, try out file sharing, commenting and restoring a previous version.
Administration and corporate tools require separate consideration. Check whether user accounts, group membership and access revocation can be managed via a central interface. The Microsoft 365 and Google Workspace administration interfaces also integrate account management with the applications. With your own email hosting, the administration interface and email management may vary from service to service. Business email associated with the domain can therefore be compared separately with the entire office system.
Project and task management often takes place in separate tools. On Trello boards, tasks can be tracked on cards, whilst in Asana they are assigned to projects. Compare these with built-in task features, such as whether a task can be assigned directly to a document. When automating, map out the process: who initiates it, what data is used, and who approves the next step. An HR task might, for example, involve creating a new employee’s account and access rights.
Neo Mail is worth considering as a business email-centred solution if email is your primary requirement. Check whether the calendar, contacts, shared documents and task tracking needed for your day-to-day work are available in the same place, or whether separate systems are required. An alternative to Google Workspace could therefore be a complete office suite, or a combination of email and separately selected tools.
| Solution | Correspondence | Document management | Task management | Administration |
|---|---|---|---|---|
| Google Workspace | Gmail | Drive, Documents | Built-in and external tools | Shared interface |
| Microsoft 365 | Outlook | OneDrive, SharePoint | Built-in and external tools | Shared interface |
| Zoho Workplace | Zoho Mail | Zoho document tools | A separate device can also be selected | Managing Zoho accounts |
| Nextcloud | By separate correspondence | File sharing | Additional applications | Depends on the installation |
| ONLYOFFICE | By separate correspondence | Office documents | With additional tools | Depends on the installation |
| Neo Mail | Email-centred | A separate solution should be considered | A separate solution should be considered | Depends on the service |
| Your own email hosting | Email linked to a domain | A separate system is required | A separate system is required | Depends on the service |
Choose a complete package if centralised administration and document sharing are your main priorities. Separate tools may be more suitable if you require a specific project or HR system.
In Google Workspace, Gmail, Drive and Google Docs operate within a single interface. Microsoft 365 integrates Outlook, OneDrive and Word. Both systems offer business email, file storage and online document editing. In contrast, a dedicated email hosting service primarily provides mailboxes associated with your domain. You can choose separate applications for files and office work. This can offer a more flexible setup, but access management may need to be handled across multiple interfaces.
When choosing cloud storage, consider the types of files and how you intend to share them. Google Drive and OneDrive support collaboration with their own office applications. For a contract, for example, it may be important to retain comments, track changes and set read-only access. Nextcloud can be used as a file-sharing system, whilst ONLYOFFICE can also provide document editing. Customised settings are useful when different levels of access need to be granted to financial, sales or management documents.
Before migration, make an inventory of your mailboxes and files. Note which accounts contain calendars, contacts, shared folders or forwarding rules. Then decide on the order of migration and start with a test mailbox, for example. IMAP can be used to transfer emails and folders, but calendars and contacts may require separate export. For files, check the owner, sharing permissions and document format. Also organise access to shared project folders so that the necessary permissions for the team are retained.
For creating office documents, Google Docs can be edited in a web browser, whilst Microsoft Word can be used in both desktop and web-based workflows. LibreOffice is an office suite that can be installed locally, whilst ONLYOFFICE offers an alternative for document management. When opening DOCX, XLSX and PPTX files, check the formatting, formulas and fonts. A complex Excel workbook or Word template may appear differently in another program. Before making the final switch, open a few files that you use in your day-to-day work.
A dedicated email hosting service and a full office suite do not serve the same purpose. With email hosting, the focus is on the mailboxes associated with the domain, setting up email clients and email authentication. An overview of email hosting solutions can help you compare the specifics of business email with the requirements of a full office system. When making your choice, consider whether you would prefer to manage email and files within a single system, or build a coordinated working environment using separate services.
Options for businesses include Microsoft 365, Zoho Workplace and a bespoke email and office suite. The best Google Workspace alternative is the one that suits your business’s day-to-day tasks, not necessarily the one that offers the most applications.
First, make a list of what your team actually uses: Outlook, spreadsheets, calendars or shared folders. Then compare user management, permissions, mobile access and collaboration features. Microsoft 365 may be the obvious choice if your staff are already working in Word, PowerPoint and Outlook. Zoho Workplace offers an integrated environment, whilst separate email and office software may require more configuration.
Microsoft 365 combines Outlook, Word, Excel and PowerPoint. Zoho Workplace brings together email and office applications, so it may be suitable for those looking for a unified service environment. LibreOffice is an office suite that can be installed locally, but it is not a complete business email system. Consequently, an alternative to Google Workspace could be either an integrated suite or a combination of separate tools.
Industry-specific workflows have different requirements. In an accountancy firm, the accurate display of Excel formulas and spreadsheets may be crucial. For a consultancy team, the focus may be on collaboratively editable quotations, the calendar and access granted to clients. For an online shop, sharing order documents and staff permissions may be important. Therefore, when choosing an alternative to Google Workspace, consider not only the industry but also the actual day-to-day tasks.
Before implementation, try out a real-world workflow. Choose a quote, an internal spreadsheet and a shared calendar entry. Open them in the system under review, then check the formatting, sharing and comment management. In a PowerPoint presentation, also check the fonts and animations. This will reveal how well the chosen Google Workspace alternative suits your team’s day-to-day operations.
To help you make your decision, draw up a brief comparison based on the following criteria:
Choose the solution that works most seamlessly with the documents you use and your industry’s workflows.
When choosing a business email service, keep the email account separate from the wider office system. Microsoft 365 integrates Outlook with other Microsoft applications. Zoho Mail can be used for business correspondence, whilst Zoho Workplace also integrates office tools. Email hosting linked to your own domain is a more independent solution if your business primarily needs corporate email accounts. Rather than focusing on price, it is worth comparing the full range of required features and administrative tasks.
As well as email, take a look at the calendar and day-to-day communication. Outlook manages calendar invitations and email workflows, whilst the other tools in Microsoft 365 can also be linked to documents. The Zoho Mail calendar is part of the email environment. If your team uses a separate application for video calls, such as Microsoft Teams, check how accounts and invitations are managed as well. When making your choice, it is important to ensure that a client meeting, its calendar event and any subsequent email correspondence can be tracked.
The address assigned to the domain, such as info@cegnev.hu, provides a consistent corporate image. For email to function correctly, the MX records in the domain’s DNS settings – which specify the route taken by emails – must be set to the values provided by the email service provider. SPF and DKIM records support the authentication of outgoing emails. DMARC rules specify how to handle unauthenticated messages. Domain registration and email account management are separate tasks, so you should also keep track of renewals and access rights.
The differences between providers are also evident in the packaging and support offered. Microsoft 365 brings together several office applications, which can be useful if your team works in Outlook, Word and PowerPoint. Slides and spreadsheets can be edited collaboratively within a single working environment. However, in addition to dedicated email hosting, you can choose a separate calendar, word processor or video communication tool. This combination may involve multiple provider accounts and settings.
Before implementation, create a test email, send it to an external address, and then test the reply, the calendar invitation and mobile login. Reviewing your domain settings will help you determine which service is compatible with your current system. Choosing the right domain registration option is an important step if you wish to use your own company email address.
When moving from Google Workspace to another provider, you should plan the transfer of your emails, files, calendars and contacts separately. Emails can be moved using IMAP-based migration or a dedicated migration tool. Google Takeout allows you to export your data, but the exported items will need to be organised separately in the new system.
Before switching, make an inventory of your Gmail inboxes, Drive folders and shared files. Make a note of the account owners, forwarding rules, calendars and group addresses. For a shared project folder, you’ll need to organise access rights as well as the files themselves. The email migration alone will not transfer all Google Docs sharing settings.
Training is more effective if staff are given guidance tailored to specific tasks. For example, show them where to find the labels in the new email system, how to share documents and how to accept calendar invitations. When switching to Microsoft 365, be sure to cover the use of Outlook and OneDrive as well. In a larger organisational setting, designate those responsible for access management and administration.
You can create a brief guide, complete with screenshots, for basic workflows. You can hold a separate demonstration on advanced software features, ensuring that day-to-day use remains straightforward. If your team works across multiple sites, make the same guide available to every workgroup. This way, staff can follow consistent steps even when using different devices.
aWh could be the natural next step if your business needs web hosting or its own domain, whilst you’d prefer to keep your email and office applications separate. Web hosting supports the operation of business websites, whilst domain registration provides you with your own web address. If your project’s resource requirements or technical environment warrant it, KVM VPS and Windows VPS may also be worth considering.
Choose business email and website hosting separately, then assess what infrastructure suits your system. That way, whilst searching for a Google Workspace alternative, you won’t forget that you may also need separate hosting for your online presence.
Find out more about what aWh has to offer at www.awh.hu.
Making the switch is a good opportunity to separate business email, file storage and your web presence. You don’t need to replace every system at once. First, identify which workflow causes the most difficulties, then choose a suitable solution for that. This way, the transition can be phased in, and staff can familiarise themselves with the new interfaces gradually.
When choosing a Google Workspace alternative, you should also consider what sort of infrastructure you need for your own website and domain. aWh offers web hosting, KVM VPS and domain registration to support your business’s online operations. As a next step, review your current system and the planned changes.
Ask the aWh team for help and take the next step towards finding a solution that suits your business needs.
Don’t just compare the number of applications, but also how well they fit in with your existing workflows. When choosing a Google Workspace alternative, check whether files can be exported, how accounts are deactivated and whether multi-factor authentication is available. For example, calendar events and shared documents must also be transferred from a departing employee’s account. Try out real team tasks, not just demo files.
Microsoft 365, Zoho Mail and our own email hosting service can all be used for business email addresses linked to a custom domain. The right choice depends on whether you wish to manage your email independently or in conjunction with office applications. aWh also offers email hosting, which enables the use of professional business email addresses. For example, for the address info@cegnev.hu, the domain and email settings need to be configured together.
Check where business data is stored, who has access to it, and how it can be deleted or exported. From a GDPR perspective, review the data processing terms, the role of subcontractors and the incident management procedure. Restrict access according to job role and enable multi-factor authentication. For example, do not automatically grant all mailbox users access to financial documents.
]]>The attackers reacted swiftly to the leak: several security firms (including watchTowr, Hadrian and Patchstack) detected active exploitation, whilst Cloudflare reported the first attacks even before the patch was released. According to a report by Amazon Threat Intelligence, the first attempts began as early as 17 October.
The two errors lie in PHP’s memory management:
Both have a CVSS score of 9.2 (critical). Using a specially crafted web request, an attacker can execute code on the server with the privileges of the PHP process. Researchers have also demonstrated that the contents of the PHP process’s memory can be leaked, which may include passwords, tokens or API keys.
As PHP processes the request before the application code, even the CMS login protection offers no defence. The greatest risk comes from Apache’s mod_php, but PHP-FPM, LiteSpeed and FrankenPHP are also affected under certain configurations.
The bugs affect PHP version 5.4 and later.
Important: the table below shows only which branches the PHP.net team (the PHP project itself) has released official patches for. This does not mean that other versions are actually left unprotected: maintenance teams for operating systems and software vendors (such as CloudLinux, cPanel, TuxCare, Debian, Ubuntu or AlmaLinux) may backport the patch to other, older PHP versions, and in practice they often do so. The situation on a given server is determined by the status of the package used there, not by the PHP version number.
| PHP branch | Updated version from PHP.net | Comment |
|---|---|---|
| 8.5 | 8.5.12 | |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | Support for PHP.net will end on 31 December 2026 |
| 8.1 and earlier | PHP.net does not release official versions | The PHP team has released a source-code-level patch for the 7.4, 8.0 and 8.1 branches; distributions and vendors may also release their own backported patches for these (and even older branches) |
The table therefore shows the official support provided by PHP.net, not which version is secure on a particular server. With us, for example, the CloudLinux and cPanel (EasyApache) plans include patches for older PHP branches as well, so older versions are also protected on these servers.
Some vendors (such as CloudLinux) backport the fix to their older version numbers. In such cases, the PHP version number does not change (for example, it remains 8.5.11), only the package build number; however, the build number is not visible in the version. The package’s changelog confirms that the fix is included.
For this reason, checks that only look at the PHP version number may give a false reading. If a WordPress plugin (such as HelloPack) indicates that the site is using PHP 8.5.11 and needs updating, this does not automatically mean that the patch is missing. If you see such an alert, please contact us and we will verify the status.
The ‘Build Date’ in the phpinfo() output is also helpful: if the date is after 21 October 2026, the package has probably been recompiled following the patch. The surest way to check is to consult the package’s changelog.
.php files, unknown users or administrators in the CMS, unknown scheduled tasks (cron jobs) in your hosting account, as well as unexpected redirects, spam or unauthorised content. If you find any of these, please report them to us and do not delete anything before we have discussed it.If you want to check your own website, you can use, for example, Searchlight Cyber’s open-source php2shell-scanner tool or Aikido’s free URL checker. Please ensure you only use these to test your own server and your own website!
All times are given in Central European Summer Time (CEST), in the YYYY-MM-DD HH:MM format.
| Date | Event |
|---|---|
| 2026-10-17 | According to the Amazon Threat Intelligence report, the first exploitation attempts began at this time, prior to the public disclosure. |
| 2026-10-20 21:33 | The PHP security team has issued an advance notice of an urgent release addressing two critical vulnerabilities. Details have leaked ahead of the official announcement, and CERT-EU has also issued a warning. |
| 2026-10-21 05:02 | Cloudflare enables its security rules by default on WAF packages. |
| 2026-10-21 09:43 | Cloudflare reports the first attacks. |
| 2026-10-21 11:08 | The first rule set for the Imunify360 WAF blocks publicly circulating attack patterns. |
| 2026-10-21 13:35 | Hadrian enables large-scale utilisation, primarily through the session upload process. |
| 2026-10-21 16:00 | The php.net team has released the following updated versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. |
| 2026-10-21 16:19 | watchTowr confirms that it has detected active exploitation attempts targeting both vulnerabilities. CISA and the UK’s NCSC have also issued warnings. |
| 21 October 2026 – ongoing | cPanel has also issued a statement regarding the updated cPanel and EasyApache 4 plans. |
| 2026-10-21 19:50 | AlmaLinux is releasing the patched PHP packages for testing (they will be added to the production repositories from 21 October 2026 at 23:15). |
| 2026-10-21 22:55 | CloudLinux has released the patched ea-php packages (ea-php52–ea-php85). |
| 2026-10-21 | Ubuntu has released USN-8948-1: updated PHP packages for Ubuntu 22.04 LTS (php8.1, 8.1.2-1ubuntu2.28), 24.04 LTS (php8.3, 8.3.6-0ubuntu0.24.04.13), 26.04 LTS (php8.5, 8.5.4-0ubuntu1.5) and 26.10 (php8.5, 8.5.9-0ubuntu2.1) releases. |
| 2026-10-21 | Ubuntu has issued advisory USN-8948-2 for older releases: 20.04 LTS (PHP 7.4, 7.4.3-4ubuntu2.29+esm5) and 18.04 LTS (PHP 7.2, 7.2.24-0ubuntu0.18.04.17+esm14) via the ESM; updates for 16.04 and 14.04 require an Ubuntu Pro Legacy Support subscription. |
| 2026-10-21 | Debian has also released updated packages: trixie (Debian 13) php8.4 8.4.27-1~deb13u1 (DSA-6574-1) and bookworm (Debian 12) php8.2 8.2.35-1~deb12u1 (DLA-4848-1). In the unstable (sid) branch, the fix has not yet appeared in the Debian tracker. |
| 2026-10-22 02:07 | The updated alt-php packages for CloudLinux are now available in the stable repositories (CloudLinux 7, 8, 9: PHP 5.2–8.5). |
| 2026-10-22 03:19 | TuxCare has released all patched packages (alt-php, the distributions’ own PHP packages, PHP for Windows). |
| 2026-10-22 14:05 | An open-source scanning tool (Searchlight Cyber php2shell-scanner) is being released. |
Will this affect my WordPress site or my online shop? Yes, it could affect any PHP-based website, as the error lies in PHP. The fix is carried out on the server.
Is it enough to update WordPress or its plugins? No. The error is resolved by a PHP fix; updating the CMS alone will not fix it.
Is my website down? For a short time, yes: the Apache and PHP restarts caused a total of just a few minutes’ downtime.
Can I continue to use PHP 8.1 or an older version? PHP.net has not released an official version for these branches, but operating systems and vendors (such as CloudLinux, cPanel and TuxCare) may release backported patches for them, meaning that older versions on affected servers may also be protected. In the long term, we recommend upgrading to a supported version (8.3 or 8.4) if your website is compatible with it. Before making the change, take a backup, then test your website. We explain how to change the PHP version in cPanel in a separate article.
]]>If you’re storing your files on your own VPS, control over your data and secure access are key considerations. During installation, the HTTPS connection, domain DNS settings and appropriate permissions are all essential. This guide walks you through preparing your VPS and installing Nextcloud, so you can understand what each setting is for.
You’ll learn how to create a database, place files in a separate data storage directory and set the necessary file permissions. We’ll also cover preparing your domain and certificate, as well as the checks you can carry out to prevent common configuration errors. This will enable you to tailor your hosting to your needs and manage access to and protection of your files more effectively.
Set up the database and the file directory separately, then check the access permissions.
To use HTTPS, point the domain’s A record to your VPS IP address, then wait for the DNS to update. You can then issue a Let’s Encrypt certificate for the specified domain.
To set up automatic backups, schedule a separate task to back up your Nextcloud data and database. Store the backups separately from the original VPS, and check from time to time that they can be restored.
Log in to the MySQL server with administrator privileges, then create a separate database and user. The Nextcloud guide recommends the database name ‘nextcloud_db’. For example, you can create it using the command ‘CREATE DATABASE nextcloud_db;’.
Use the CREATE USER command to create a unique user, then grant them access exclusively to the nextcloud_db database. In the installer, enter the same database name and username, along with the corresponding password. Do not use the administrator account within the application.
If you choose MariaDB, install version 10.6 or 10.11 as recommended in the Nextcloud guide. As with MySQL, first create a separate database, for example named nextcloud_db. Then create a dedicated user for it and grant the necessary database permissions.
In the installer’s database settings, select the MySQL/MariaDB option, then enter the server address and authentication details exactly as required. Configure either MySQL or MariaDB as the database server. Configuring both is unnecessary and may make troubleshooting more difficult.
Create a separate directory for user files, for example at the path /srv/nextcloud-data. Specify this as the data storage directory in the Nextcloud installer. Do not confuse this with the location of the application files, such as the Nextcloud directory served by Apache.
Set the directory owner and permissions so that the user running the Apache process has access. However, do not make the directory writable by all system users. Before installation, check the available hosting and that the path is accessible.
Nextcloud requires a LAMP server based on Linux, Apache, MySQL and PHP to run, so please check these components before installation. The Nextcloud installation guide provides examples in the PHP settings of a maximum upload size of 100M and a max_execution_time value of 360 seconds. Regarding the PHP Opcache settings, the guide provides an example for PHP version 7.4 and, from Nextcloud version 12 onwards, recommends configuring Opcache to avoid error messages. Please check these parameters in the PHP configuration appropriate for your chosen installation method.
To install Snap manually, use the nextcloud.manual-install command and enter an administrator username and password. When selecting the installation method, please note that the LAMP environment and the Snap-based installation require different steps.
Installing Nextcloud on a VPS begins with selecting the operating system and setting up an SSH connection. On an Ubuntu VPS, first check the server status, administrator access and domain configuration.
Ubuntu 22.04 LTS is highly recommended; Ubuntu 24.04 LTS and Debian 12 can also be used. Without a domain, the server can be accessed via its IP address.
Choose from the systems compatible with Nextcloud. Ubuntu 22.04 LTS is recommended, whilst Ubuntu 24.04 LTS and Debian 12 may also be suitable. You can install Nextcloud on a VPS via an SSH connection, once you have checked that you can run administrator commands.
Only use the automatic installation script on a clean system that meets the requirements. The script provided can be run on Debian 9/10, Ubuntu 18.04 or CentOS 7 installations. If a web server, such as Apache, is already running on your VPS, it is better to opt for manual installation. This reduces the risk of conflicts with existing services.
For an Ubuntu 18.04 VPS, connect via SSH and check the system status. On a clean Ubuntu 18.04 installation, you can use the automatic Nextcloud installer. Before running it, make sure that no other web server is already running. If there is, a manual installation will be better suited to your existing server configuration.
The installation script installs the Apache web server, a MySQL database, Certbot and other dependencies. The example in this guide uses Ubuntu 20.04, whilst Ubuntu 22.04 LTS is the highly recommended version. When setting up a new VPS, you should therefore select the recommended version and base your decision on the installation’s system requirements.
Before starting the installation, connect to the server via an SSH connection and set this up. It is worth checking the connection before starting the Nextcloud installation steps, so that accessing the server does not become a task to be dealt with later. Connecting via SSH is therefore part of the installation preparation, rather than a task to be dealt with whilst setting up the application. When you start the installation, you should be clear about which VPS you are connecting to and that you intend to carry out the following steps on that VPS.
Setting up a domain or subdomain can help ensure that Nextcloud running on your VPS is accessible by name. Choose a name to assign to this VPS and set it up before installing the application. Use the same name consistently in the following steps. This ensures that the domain required for access and the VPS IP address specified as the destination will match. Before installation, make sure that the chosen name points to the correct VPS.
A traditional installation places the Nextcloud files directly on the web server, whereas when using Docker, the application runs in a container. Choose the method that suits your server’s current configuration. If you have an existing web server, manual installation is recommended.
Common causes of errors include incorrect file paths, incomplete extraction or insufficient access rights. Check the contents of the package, its destination directory and the web server’s permissions, then download and extract it again if necessary.
Select the appropriate compressed package for installing Nextcloud, then download it to your VPS. The installation guide provides an example using a file for Nextcloud version 18. When selecting a version, the compatibility of the PHP and web server environment you have set up should be the deciding factor.
Work via an SSH connection and store the downloaded package in a temporary directory accessible to the administrator account. You can filter out empty or incomplete packages by checking the file name and the download result. Do not start the installation until the file is available on the server.
After downloading, view the contents of the directory and identify the compressed file. If the name or extension of the package differs from what you expected, check the destination of the download command. In the next step, extract the correct file into a directory accessible to the web server.
Select the target directory served by Apache, then extract the Nextcloud package into it. In the previous installation example, the application path was /var/www/html/nextcloud/. After extraction, check that the application files have appeared and that no unnecessary, nested folder structure has been created.
The web server needs to be able to read the application’s files, whilst Nextcloud needs to be able to write to the necessary locations. Do not grant unrestricted write access to all files. If the installer cannot find the application, first check that the target directory, the name of the extracted folder and the path configured in Apache match.
Unpacking the files alone does not set up the database user. The GRANT ALL PRIVILEGES command applies only to the Nextcloud database, not to the entire MySQL server. In the installer, enter the database username and password you set up earlier.
Nextcloud running on a VPS acts as your own cloud storage, and you can control the server configuration yourself. The following steps explain how to check file synchronisation, performance and day-to-day operations.
Configure Nextcloud’s file permissions, then check the firewall and for updates. To ensure your VPS runs securely, only allow the necessary network access and carry out maintenance whilst maintenance mode is enabled.
occ maintenance:mode --on, and then disable it at the end of the operation using the command occ maintenance:mode --off. Run the command from the Nextcloud installation directory. Once the operation is complete, switch off maintenance mode. Open the web interface, log in, and then try to access a file. This will allow you to check whether Nextcloud is working again.localhost address but not via the domain, check the web server settings and network rules.occ maintenance:mode --off again. If the site is still unavailable, check your Apache or NGINX settings, as well as your firewall. Error messages and logs will help you distinguish between application and network issues.aWh offers web hosting to those who, in addition to running Nextcloud on their own VPS, would also like a website or separate hosting. The right solution depends on whether you wish to manage your own server environment or host your web content on a web hosting service. With domain registration, you can also manage a domain name that suits your service, whilst email hosting provides a separate email solution.
If configuring, updating and performing a backup on your VPS involves too much administration, consider which tasks you’d prefer to manage yourself. aWh also offers web hosting, domain registration and email hosting. Take a look at aWh’s web hosting options and choose the solution that best suits your needs.
Installing Nextcloud on a VPS is not just a technical setup; it’s also about how you want to manage your own server environment. Think about how much time you can devote to monitoring the system, and which tasks you’d like to handle yourself. This will help you determine which infrastructure best suits your workflows.
If you’d like your own server environment, aWh offers KVM VPS. You can also arrange the web address used to access Nextcloud through domain registration. Take a look at the options and choose the next step that best suits your needs.
Get in touch with aWh and take the first step towards finding a solution that meets your needs.
The resources required are determined by the number of users, the frequency of file operations and the authorised applications. Multiple simultaneous uploads, generating file previews and running background tasks can also increase the load. Choose a VPS that provides sufficient space not only for files but also for the database and system operations. Monitor memory and CPU usage whilst using the service.
Ubuntu LTS may be a suitable choice if a transparent installation process and a widely used Linux environment are important to you. When selecting a distribution, take into account your system administration experience, the availability of installation tools and compatibility with existing server applications. After installing the system, manage dependencies using the package manager and consistently follow the same configuration procedure.
Select a web server and configure the PHP execution mode and Nextcloud’s database connection accordingly. Do not set up multiple web server configurations running in parallel that serve each other. After installation, check that the web server can access the application’s files, that PHP is processing requests, and that the database accepts connections from Nextcloud’s own user. In the event of an error, check the log for the relevant service.
]]>A short validity period does not in itself require any regular manual action: provided the settings are correct, the certificate is renewed automatically in the background. However, if the domain does not point to the correct server, or if the validation fails, both issuance and renewal may be blocked.
This guide explains how to install a certificate in cPanel, check its validity and renewal status, and redirect HTTP traffic to HTTPS. In the section on common errors, we also outline which DNS and server settings you should check to ensure your website is accessible via a secure connection.
After installation, please check the certificate status, domain accessibility and the HTTPS connection separately. The Let’s Encrypt certificate is valid for 90 days, so it is also worth keeping an eye on the renewal status in cPanel.
What is the difference between Let’s Encrypt and a paid SSL certificate in cPanel? According to the Internet Security Research Group (ISRG), Let’s Encrypt certificates can be obtained free of charge. The terms and conditions of paid certificates depend on the issuer and the specific certificate in question, so the price alone does not reflect the technical differences.
Open the website via an HTTPS connection, for example the homepage and an internal page. Check for the padlock icon in the browser’s address bar, then view the certificate details. Ensure that the certificate is for the correct domain and that the browser indicates it is valid. The absence of the padlock alone does not prove that the installation has failed.
If you’re looking for information on cPanel’s SSL/TLS settings, the section on managing SSL/TLS certificates will also help you understand the key points to check.
Open the certificate details and compare the domain name with the website address. For example, the certificate for pelda.hu must also include the www.pelda.hu version if the website is accessible via that address as well. Check the issue and expiry dates, and ensure that the browser does not display a trust error. The expiry date is particularly important due to the 90-day validity period.
On HTTPS pages, check images, style sheets and scripts as well. If these are loaded from an HTTP address, the browser may flag the content as mixed, even if the certificate is valid.
Look for the entries relating to the domain in question in the renewal log, and compare the status shown there with the information displayed on the Status tab under the SSL/TLS Certificates menu in cPanel. If a log is available via your hosting control panel, make a note of whether a renewal attempt was made and what the outcome was. If an entry is missing or has failed, check the domain’s HTTPS access again, then verify that the certificate is still valid for the correct domain names. Let’s Encrypt certificates are free, and anyone with a domain name can apply for one, according to the Internet Security Research Group (ISRG).
The log and browser feedback can together help you distinguish between a certificate nearing expiry and an installation or access issue. Don’t just check the homepage: also check the domain variants and pages that you actually use. If there is a discrepancy, make a note of which domain was affected, what cPanel displayed, and what the browser indicated. This makes it easier to check later and helps you track whether the error has been resolved. It is also worth reviewing the certificate status at a later date, particularly if the outcome of the renewal is unclear.
Check the domain’s DNS settings, the firewall and the cPanel status indicators for the cause of the request error. Work through the checks below, then try the process again after making any changes.
Once the certificate has been installed, redirect HTTP addresses to HTTPS. The cPanel guides recommend a permanent 301 redirect. This ensures that the browser requests the encrypted version when a visitor opens the old address.
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP\_HOST}%{REQUEST\_URI} \[R=301,L\]
REQUEST_URI preserves the path and the requested page. For example, the URL http://pelda.hu/kapcsolat redirects to https://pelda.hu/kapcsolat. Place this rule before the content management system’s automatic rules so that the redirect runs first.
An HTTPS address using port 2083 is used to access cPanel. Open the control panel at this address, then check the changes made to the website’s root directory in the file manager. Establishing the connection to log in and testing the website’s redirection are two separate steps: first, use the correct cPanel address, then check that the visitor-facing page is working correctly.
You can check your certificates and access the installation options via the cPanel SSL/TLS interface. The names of the menu items may vary depending on the version of the interface and your hosting settings.
To use Let’s Encrypt, the domain must point to the IP address of your cPanel account. The hosting platform must support the issuance and renewal of certificates, for example through AutoSSL integration.
aWh’s web hosting could be the natural next step if you’re looking for hosting for your website and domain-related services. If you get stuck with the cPanel SSL settings, it’s important to configure your hosting and domain correctly in order to issue and renew your certificate.
When making your choice, consider where your website’s files are hosted, which IP address the domain points to, and what cPanel features are available. If you need a dedicated server environment, aWh also offers KVM VPS. If you don’t yet have a domain, you can manage your website’s address and hosting together with your domain registration.
Find out more about aWh’s web hosting service, or visit awh.hu.
After installing Let’s Encrypt SSL via cPanel, make certificate management part of your website’s regular maintenance tasks. Make a note of which domains belong to the site, where you have set up the redirects, and which cPanel interface you can use to monitor the certificate’s status. This way, you’ll be able to find the relevant settings more quickly should you need to make any changes later on.
Before you migrate your website, change the DNS settings or add a new subdomain, consider how the change will affect HTTPS access. Making notes in advance will help ensure that no old addresses, redirects or domain settings are overlooked. Maintaining a secure connection also depends on ensuring that the certificate, application and hosting settings are all in sync.
If you need practical help setting up your hosting or domain environment, please contact the aWh team.
Ask the aWh team for help and make the running of your website more transparent.
Our knowledge base article describes the steps to follow on aWh’s web hosting service: Enabling a free Let’s Encrypt certificate on your web hosting account.
Automatic SSL manages the issuance and renewal of certificates for domains assigned to your cPanel account in the background. The process checks the domain’s availability and, following a successful check, installs the certificate. Renewal can also take place automatically if the hosting platform has integrated AutoSSL or the Let’s Encrypt extension. It is worth keeping an eye on the domain’s status and any error messages in cPanel.
The certificate is installed on the domain names selected at the time of application and assigned to your cPanel account. These could include, for example, pelda.hu, www.pelda.hu or a subdomain such as shop.pelda.hu. Please check the names covered in the certificate details, as the website may be accessible via multiple addresses. Do not assume that all names listed in the cPanel domain list are automatically covered.
The activation time depends on the processing of the request and the verification of the domain. cPanel must successfully access the domain required for verification and then install the issued certificate. If the DNS settings have recently been changed, the verification process may still see the old destination address. Please follow the status message in cPanel and only test the HTTPS version once the installation has been successfully completed.
Read the cPanel error message and make a note of which domain is affected. Then check whether the domain and the www version point to the hosting IP address, and whether port 80 – required for HTTP-based checks – is accessible. Also check whether a parked domain is redirecting to another server. Once you have rectified the cause of the error, restart the certificate request.
To install Let’s Encrypt SSL in cPanel, log in to your account and open the ‘Status’ tab under the ‘SSL/TLS Certificates’ menu. Select the domain you wish to secure and its associated names, then initiate the certificate request. Wait for confirmation of the installation and check your website’s HTTPS address. If the interface uses AutoSSL, follow the status indicators for the domain.
On aWh’s cPanel hosting, open the ‘SSL/TLS Certificates’ menu item in the ‘Security’ group, then select the ‘Status’ tab: here you can view the certificates and expiry dates for all your domains, and manually run AutoSSL (‘Run AutoSSL’). AutoSSL does not have a separate menu item.
Configure your domain’s DNS records to point to the IP address of your cPanel account. Check the same for the www version as well, if your website uses it. For HTTP-based verification, port 80 on the server must be accessible. A request initiated from cPanel can only verify access to the domain if the requested name is routed to the correct server and the verification request reaches the website.
When requesting a certificate, please select the main domain and the www version separately if you use both. If your cPanel domain list offers them, include subdomain names, such as blog.pelda.hu, in your request. Before applying for a wildcard certificate, create the appropriate subdomain in the format *.pelda.hu in the cPanel Domains section. After installation, check the certificate details to see which names it covers.
]]>If you’re looking for an error or want to understand what search engine bots are crawling, the web server log provides detailed information. Each entry records a request received by the server, including requests from bots. The user-agent field can help you identify the type of request, but on its own it does not prove that the request was actually sent by the bot in question.
Below, you’ll learn about the key fields in log entries and the meanings of the most common HTTP codes, as well as how server logs differ from web analytics. We’ll look at how they can be used when analysing bot traffic, and when it’s best to use a spreadsheet program or a log processing tool. This will give you a clearer picture of what is happening on the server and which errors require attention.
The web server sends an HTTP response to the browser, and the status code indicates what happened with the request. Interpret the code in the log alongside the relevant URL, timestamp and request.
From a GDPR perspective, an IP address or other identifier in a log may contain personal data. Therefore, the purpose of data processing, as well as access and retention, must be managed in a restricted and transparent manner. In Hungary, too, these data protection considerations govern the handling of web server logs.
The risks associated with log storage include unauthorised access and retention for too long. Minimise these risks by restricting access rights, protecting stored data and removing unnecessary log data.
An HTTP response is the server’s reply to a request from a browser or other client, and the status code summarises the result of this response. A 200 code indicates a successful request, whilst a 301 indicates a permanent redirect and a 302 indicates a temporary redirect. Checking these helps to determine whether the user is reaching the expected page or is following an incorrect redirect path.
Analysing HTTP error codes helps to identify the types and frequency of faulty requests in log entries. According to the Internet Assigned Numbers Authority (IANA), 4xx status codes indicate a client error, whilst 5xx status codes indicate a server error, so these can be used to measure the distribution of errors. A 404 code indicates a requested page does not exist, whilst a 503 code indicates a server that is temporarily unavailable. You should also examine the relevant URLs and timestamps.
In practice, first group the entries by status code, then identify which files or pages are duplicated. For example, a 404 response may result from a typo, removed content or a broken internal link. Recurring 503 responses, on the other hand, may indicate a server-side availability issue. The status code alone does not reveal the underlying cause, so examine it alongside the timestamp and the relevant request.
The ideal HTTP response code for website pages is 200 or 301. If the old address of a moved page returns a 404 error, check the redirect rule. Meta refresh redirects are not recommended from an SEO perspective; instead, a permanent 301 redirect is advised. A poorly targeted redirect can still mislead the user even if no error code is generated, so please also check the destination page.
The Apache HTTP Server access log can be used to analyse requests and responses. On Debian and Ubuntu systems, the default log location is /var/log/apache2/access.log, whilst on RHEL, Red Hat, CentOS and Fedora systems it is /var/log/httpd/access_log. On FreeBSD systems, the file is located at /var/log/httpd-access.log. Knowing the correct path helps you quickly find the entry for a specific request.
Look up the relevant time, URL and HTTP status code in the Apache log, then compare them with similar requests. For example, if the same page repeatedly returns a 404 error, check whether the page’s URL has changed or whether the file is actually accessible. Among other things, the temporal pattern of recurring 5xx responses can also help distinguish between an occasional error and a persistent server issue.
The web server receives and processes incoming HTTP requests, then sends a response to the client. From the log entries, you can see which pages were requested by search engine bots, how often they returned, and how long the crawling took.
Analysing how search engine bots crawl a website involves reviewing the requests they send to the server. It shows which URLs are being crawled and helps you spot if important content is being missed or if attention is being directed to incorrect URLs. The log can record every request that actually reaches the server, including those from bots.
Search for entries based on the user-agent field, then compare the timestamps and the requested URLs. For example, if a bot regularly requests the same address, check whether the page is accessible and whether the server returns the expected response. If the log also contains requests from users’ browsers, the nature and frequency of these requests can help you distinguish between different types of traffic.
The crawl analysis shows the crawl pattern based on the pages requested by the bots, the frequency of requests and the processing time. This is useful because it reveals what the bot is focusing on and where technical issues may arise. The log may also show the duration of the crawl in milliseconds.
Group requests by URL families, such as product pages, images or search results. Then check whether the bots return to the same pages and reach the important content. If you see a lot of invalid or low-value URLs in the log, you can use the entries to find out which URLs the requests are directed at. The pattern also shows whether the site crawl consists of quick, short requests or longer server processes.
The user-agent is a text identifier included in an HTTP request that identifies the browser or software acting as a robot. It is a useful filtering criterion, but on its own it does not verify the genuine origin of the request. The text ‘Googlebot’ appearing in the log entry is therefore merely an indication, not conclusive proof that the request was actually sent by a Google bot.
When evaluating, do not just take this field into account. Compare the paths of requests marked with the identifier, their distribution over time and the server’s responses. If the user-agent indicates a bot, but the requests repeatedly access unusual pages, treat this as traffic requiring further investigation. You can certainly determine from the log what HTTP request the web server received and what response it sent, but you cannot necessarily determine who was behind the request.
Together with log analysis software, you can filter user-agent values, URLs and timestamps. This allows you to compare requests identified as coming from bots with the pages actually requested and the response times. Analysing web server logs makes it possible to map out browsing patterns, whilst identifiers must still be interpreted with caution.
To analyse Apache and Nginx logs, first locate the relevant file, then select a tool appropriate for the volume of the log. Smaller files can be filtered using a spreadsheet program; for processing large volumes of web server access data, a log analysis system is recommended.
When analysing Apache and Nginx logs, first identify the file, then select a time period, filter by URLs or status codes, and finally compare any recurring entries. For Apache, the location of the log depends on the system; for Nginx, the default directory is var/log/nginx/.
You can also process and segment smaller log files in Excel. Splunk, Sumo Logic and the Elastic Stack are log processing tools that can help you make sense of larger volumes of data. The choice depends on the size of the log file, as well as the required filtering, searching and aggregation.
A spreadsheet for small datasets. If the format allows, organise the log fields into columns in Excel. Then filter the rows by, for example, URL or HTTP status code, and tally up the duplicates. This allows you to quickly see which entries relate to a selected file or page. With large datasets, manual sorting and filtering becomes cumbersome, so it is advisable to use a specialised log analyser.
Specialised systems for larger datasets. Splunk, Sumo Logic and the Elastic Stack can be used to search, filter and visualise logs in a clear and organised manner. For example, if you are searching for a specific URL, you can compare the requests recorded in the Apache or Nginx logs. Filtering by status code helps to distinguish between failed and successful responses. When selecting a tool, consider how the data is ingested, which fields you can search, and what kind of aggregations you require.
The method of processing also depends on the file format. In a spreadsheet program, incorrect interpretation of field delimiters or quotation marks can cause data to be misaligned. Check against a few original log entries to ensure that the timestamp, the requested URL and the status code have been placed in separate fields. In search systems, consistent field names make Apache and Nginx entries comparable.
Start your analysis with a specific question: which requests were sent to a particular page, and how did the web server respond to them? Then expand your search to other URLs or time periods. This will allow you to compare the error detected in the browser with the corresponding log entry, making it easier to link your observations to a specific server response.
Adjust the processing method to suit the size of the log file. You can read and segment smaller log files using standard data processing programs, such as Excel. First, check that the fields are correctly separated, then sort and filter the data according to the criteria relevant to the issue under investigation. The overview remains more manageable if you do not immediately extend the search to every entry, but instead focus on a selected URL, response code or time period. Compare the results with the original log entries as well; this will make it easier to spot any misinterpretations of the fields. When dealing with large volumes of server access data, a specialised tool is required rather than manual analysis. The search and filtering options offered by these tools can help you review the data, whilst standardised field names make it easier to compare Apache and Nginx entries. Before embarking on a more extensive analysis, define the question you are seeking to answer and check whether the selected fields provide sufficient information. If not, adjust the search or aggregation, then re-examine the relevant entries. In this way, you can tailor the method to the size of the log and the purpose of the analysis.
Analysing web server logs involves examining request log entries, which show what data the server has served. Log files may record the date, time, time zone offset, IP or DNS address, request, response code and data size. You can estimate traffic by aggregating the requests; you can only measure response time if the log contains this field. The error rate can be calculated by comparing the number of failed requests with the total number of requests.
The Common Log Format is a logging standard used by web servers, which displays requests in a standardised field order. This allows you to look up who requested what content and when, and then compare the request with the server’s response.
In an entry, the address may be an IP or DNS address, whilst the time may be displayed with a time zone offset. The request field may contain the path and the protocol used. In addition to the response code, the size of the served object may also be listed in bytes. By examining these fields together, you can distinguish, for example, between a page request and the download of a larger file.
When reading the format, proceed from left to right: first identify the timestamp and the requested URL, then the response code. Next, check the data size. If you see an unexpectedly large value in a line, check which page or file it relates to. The exact set of fields may also depend on the logging settings.
The web server log consists of unique request lines with timestamps, thus showing server-side access to pages and files. This makes troubleshooting easier, as the entries can be analysed without JavaScript code or cookies.
The log may contain the visitor’s IP or DNS address, the time of the request, the requested resource, the transfer protocol, the amount of data transferred and the browser type. Web server logging may also record files stored on the server and subsequently downloaded. This makes it possible, for example, to check whether the server served an image or a document.
A log entry does not necessarily correspond to a single person or visit. The same IP address may be used by several visitors, and dynamic IP addresses may change over time. Furthermore, access via a browser’s cache or a proxy server may not necessarily appear in the log that records direct server accesses. Therefore, the number of log entries alone does not reflect the number of unique visitors.
The number and distribution of requests can be summarised from the log, providing a server-side view of visitor traffic. However, the total number of requests is not the same as the number of unique visitors, as loading a single page can trigger multiple file requests.
To analyse response times, you need a log field that records the duration of the request. The Common Log Format does not include such data in its basic fields, so please check whether the web server’s extended logging records this information. If the duration is included in the log, you can use URL-based grouping to identify which pages take longer to serve.
To calculate the error rate, compare the number of error responses with the total number of requests during the same period. 4xx codes indicate a client error, whilst 5xx codes indicate a server error. For example, counting 404 responses separately from the total number of requests shows the proportion of ‘page not found’ errors. Break the result down further by URL and date to see whether the error is linked to a single address or multiple pages.
The server log records individual requests received by the web server, whilst web analytics aggregates visitor behaviour. Logs provide direct data on the content served by the server, which is why requests from bots and file downloads may also appear in them. Analytical measurement, by contrast, often uses JavaScript code or cookies.
Retain server logs for as long as is necessary for troubleshooting and operations. Storage requirements increase in line with traffic and the volume of logged requests. On high-traffic websites, files can accumulate rapidly, so additional storage resources may be required.
The two data sources answer different questions. The log shows what requests the web server received and what responses it provided. Web analytics can also display behavioural metrics such as the bounce rate, which the server log does not provide on its own. Logs therefore complement the analysis, but they are not the sole source for examining visitor behaviour.
The log file consists of individual request lines, each with a timestamp. Opening a single page can result in multiple lines, as the browser may send separate requests for images, style sheets and other files, for example. Therefore, the number of lines or requests is not, in itself, the same as the number of page views or unique visitors. Requests from bots may also appear in the web server log.
The log can also reveal server-side events that are not recorded by JavaScript-based monitoring. Analysing served files and direct requests, for example, can help determine whether the server has served a PDF document or an image. In contrast, requests originating from the browser’s cache or via a proxy server do not necessarily appear in the log that records direct server accesses.
Dynamic operations within the site do not always appear as separate log entries. An AJAX operation may be recorded in the server log if it triggers an actual server request; changes carried out solely within the browser do not constitute a new server request. To gain a more complete understanding of visitor activity, it is therefore advisable to interpret the log and web analytics data together.
Even IP addresses cannot always be used to determine the exact number of visitors. Dynamic IP addresses may change, whilst the same IP address may be used by several users. Visitor statistics derived from log traffic should therefore be interpreted with caution. To interpret the data reliably, treat requests, visits and estimates of unique users separately.
When conducting a practical analysis, first determine whether you wish to analyse technical errors, file serving or visitor behaviour. Then select the appropriate data source: use logs to analyse error codes and server requests, and web analytics for behavioural metrics. By aligning the time period and the pages concerned, you can compare the two views without treating the number of requests as equivalent to the number of visitors.
When analysing web server logs, it is important to bear in mind that the number of requests is not the same as the number of unique visitors. Intra-page AJAX operations do not necessarily appear in the log file if they do not involve an actual server request; according to aWh’s experts, traffic data in log files may be inaccurate in the case of dynamic IP addresses or multiple visitors using the same IP address.
aWh offers web hosting for running websites. If, based on log analysis, you need to review your hosting environment or available resources, choosing the right hosting plan may be the next step.
The right solution depends on your needs. Web hosting may be suitable for running a website, whilst a KVM VPS provides a different server environment. aWh’s range of services also includes domain registration and Windows VPS. When making your choice, consider the environment in which your website runs and the tasks you wish to carry out.
Take a look at aWh’s web hosting solutions, or visit www.awh.hu.
Analysing web server logs helps with decision-making when specific actions can be derived from your observations. Make a note of which errors recur, which requests are unusual, and how the log pattern changes following each modification. This allows you to compare the server’s performance and search for the causes of problems in a more targeted manner.
Establish a process whereby only authorised personnel have access to the logs, and ensure that analysis is tailored to operational needs. If, based on the results, you decide to review your website’s technical environment, consider what resources and configurations are required to ensure stable operation.
If you’d like to review the next technical steps, please get in touch with aWh. A systematic troubleshooting process, starting with the log entries, can help you plan more effectively.
The web server logs events relating to incoming requests, and the administrator can use these for troubleshooting or analysing operational patterns. If you have made a change following an error, make a note of the time, then compare the entries generated before and after the change. A consistent time zone and the logging of changes make it easier to link events together.
You can find the logs in the hosting control panel, the server’s file system or the logging interface of the operating environment. Look for access and error logs, then check whether there are any archived or compressed files alongside the current file. Older logs are often stored in a separate file. If you are using a control panel, its log viewer may display the available entries.
A log file is a data file that records events for later analysis. In a web server environment, separate access and error logs may be generated: the former helps you track requests, whilst the latter helps you review problems reported during operation. When troubleshooting, first decide which event you are looking for, then select the appropriate log. A copy of the original file preserves the initial state for the investigation.
The purpose of bots depends on how they operate: some collect content for search engine indexing, whilst others automatically monitor or retrieve data. It is not always possible to determine the creator’s intent from the log file alone, so it is better to examine the impact on the website. Check whether the requests are overloading resources or accessing paths that should not be public.
Adapt the tool to the log’s format and processing method. In a spreadsheet, first check that the fields are properly separated, then use filters and sorting. With Splunk, Sumo Logic or Elastic Stack, standardising the fields makes searching easier. When working in a team, access control, the sharing of queries and the retrievability of archived data are also important considerations.
Search the log for requests associated with incorrect responses and group them by path, time or affected function. A recurring 404 error, for example, may indicate an outdated link or removed content; check whether the URL has changed. If several pages are returning errors at the same time, compare the occurrence with any configuration or content updates to narrow down the possible causes.
It analyses suspicious patterns by cross-referencing multiple log sources, such as web requests against authentication events. Particular attention should be paid if there are a large number of attempts targeting protected functions within a short period, or if a series of errors appears following an unusual request. Retain the original logs for the period under investigation, restrict access, and document your observations with timestamps.
The tools include spreadsheet programs and specialised log processing systems, such as Splunk, Sumo Logic and Elastic Stack. Don’t choose a tool based solely on its name: consider how the logs are ingested, what formats need to be processed, and who will have access to them. It is also worth defining your search, archiving and alerting requirements in advance to ensure the tool fits in with day-to-day operations.
]]>If you’re unsure where to find the data, or are worried that making a change might cause an error, it’s worth simply having a look at the database first. You can manage MySQL and MariaDB databases via the phpMyAdmin graphical interface. On cPanel hosting, you’ll find it amongst the database management options. The key to using it safely is to first identify the correct database, understand the impact of the selected operation, and create a backup before making any significant changes.
The article outlines the main sections of the interface, the roles of databases, tables and records, as well as common tasks such as viewing, importing and exporting data. This makes it easier for you to recognise when simply checking data is sufficient, and when you need to exercise particular caution when modifying your website’s database.
phpMyAdmin is a browser-based database management interface that allows you to view and manage MySQL and MariaDB databases. It is not the database server itself: the server stores and processes the data, whilst phpMyAdmin provides graphical access to certain operations. The ‘What is phpMyAdmin?’ summary provides further background on the tool’s history and usage.
In a web hosting environment, phpMyAdmin is usually accessible via the hosting control panel. In a cPanel environment, you’ll find it amongst the database management options. cPanel hosting is also a good example of how the tool relates to web hosting management. When learning the basics of phpMyAdmin, it is important to understand that whilst a website’s content and settings may be stored in the database, phpMyAdmin is not the website’s editing interface.
Once you have opened the interface, you can select the database and then its tables. In an online shop database, for example, one table might store the products, whilst another stores the orders. In the table view, you can view the records, search for a specific value and, depending on your permissions, edit the data. The names and structure of the tables may vary from one website to another.
Common tasks include:
Importing and exporting involve working with files, so please choose the appropriate database and file carefully. The content management system interface is still used for editing posts and pages. phpMyAdmin is intended more for database-level monitoring, maintenance and targeted interventions.
The phpMyAdmin interface is a tool for managing databases, whilst SQL is the query language used to issue commands to the database. Certain tasks, such as viewing or searching for records, can also be carried out using graphical controls. On the SQL tab, you can write queries directly, for example to retrieve or modify data. The interface therefore does not replace SQL, but provides more convenient access to a range of database operations.
As a beginner, do not run unfamiliar SQL commands without checking them first. An incorrect modification command may affect multiple records, whilst a deletion may result in data loss. Before executing a command, check which database is selected and exactly which table or data it applies to. The basics of phpMyAdmin involve not only knowing the buttons and menu items, but also assessing the impact of the operation.
In phpMyAdmin, data is displayed in nested layers. A database is a collection of related tables, whilst a table organises data of a specific type. The tabular view may look familiar, but here every column and field has a specific role. Understanding these differences is an important part of the basics of phpMyAdmin, as it helps to distinguish the data values from the storage structure.
When you select a database, the interface displays the tables it contains. The table name refers to a group of data, and when you open a table, you will see rows and columns. The column names indicate the individual attributes, whilst each row contains a complete record, i.e. a set of related data. The names of the tables and columns vary from website to website.
Imagine a table storing blog posts. The columns could be, for example, title, text and publication date, whilst a row summarises the details of a specific post. The value at the intersection of a column and a row is the field. Thus, the title field in a given row contains only the title of that particular post, not the entire record.
In the left-hand navigation pane of phpMyAdmin, you can switch between databases and tables. Once you have selected a table, you can view the records and field names. First, open the table in read-only mode: check the database name, the selected table, and then whether the displayed columns contain the information you are looking for. You can find further information about the tool and its documentation on the official phpMyAdmin website.
The data type determines what sort of value a field can store. A field can be, for example, text, an integer or a date. This is not merely a label: the database handles the value based on this, so changing the field type may also affect data processing. You can view the details of the table structure in the ‘Structure’ view of phpMyAdmin.
A primary key uniquely identifies a record within a table. For example, in a posts table, a separate identifier field can fulfil this role. It enables the system to distinguish between individual rows even if their title or other field values are identical. The name and structure of the key depend on the database schema.
It is important to distinguish between modifying data and modifying the structure. Overwriting the value of a record field changes the data itself, whereas deleting, renaming or changing the data type of a column affects the structure of the table. The website’s code may rely on specific field names and data types, so structural changes may cause operational errors. Do not delete an unknown field simply because its name is unclear. If you are managing the database on a cPanel hosting account, ensure you distinguish between viewing and modifying the structure within the cPanel hosting environment.
The complexity of the task helps you decide whether to use phpMyAdmin’s graphical controls or an SQL query. Browsing the interface is usually sufficient for viewing the contents of a table. SQL may be more efficient for targeted data retrieval based on multiple criteria, but it is not necessary for beginners. Part of understanding the basics of phpMyAdmin is realising that both methods perform operations on the same database, so even clicking through the interface is not automatically risk-free.
| Task | Surface-level solution | Using SQL | Key safety considerations |
|---|---|---|---|
| Overview of the table’s contents | Open the table in your browser. | Records can also be displayed using a data retrieval command. | Please check that you have selected the correct database. |
| Simple search | Use the search box or the filter options. | You can narrow down your search results using filters. | Check which column the search applies to. |
| Editing a record | The value of a field can be edited using the editing controls. | With the right instructions, targeted modifications can be made. | Before running the script, check the table and the relevant records. |
If you want to browse a table, look up data associated with a record or check the value of a field, the graphical interface is a good place to start. In table view, it is easier to compare column names and records, and you can use the search function to narrow down the data displayed. The interface’s controls mean you need to type fewer commands, but they do not prevent you from selecting the wrong data.
Please exercise particular caution when making changes. Check the database and table names, then check which record and field you are editing. You can also change live website data using the graphical editor. Speed is no substitute for checking.
SQL can be useful if you want to retrieve data using precise criteria, or perform an operation that graphical interfaces do not cover conveniently. You don’t need to start with SQL: browsing tables and performing simple searches can also be done using interface controls. The MariaDB documentation explains how to manage phpMyAdmin and MariaDB databases, including the tool’s role in database management.
Before running a command, define what you want to achieve, then check the database, table and conditions specified in the query. Do not copy in an unfamiliar command without checking it first. If you manage database access via cPanel hosting, you’ll find phpMyAdmin on the cPanel interface; you can then choose either the graphical view or the SQL tab to carry out the operation.
Work carried out in phpMyAdmin should be targeted and verifiable. Searching and viewing simply provide information, but making changes can affect the website’s data. The practical part of the phpMyAdmin basics is therefore a step-by-step process: preparation, identifying the database, carrying out the operation, and then checking the result.
Searching and viewing are a good first step towards getting to know the interface. These allow you to practise selecting a database and a table without having to overwrite any values straight away. Before making changes to a live website, it is particularly important to back up your work and carefully check your target.
Before making any changes, check the database and table names, then review the current contents of the record. Ensure that you are editing the correct field and only changing the necessary value. If you have a test environment, test the effect of the operation there first; do not use data from the live website for experimentation.
If the purpose of a field or record is unclear, stop and take a closer look. The backup is an important precaution, but it does not in itself guarantee that the data can be restored later. You should also check that the backup file exists and is readable.
Exporting allows you to save database data to a file, for example for later processing or archiving. When importing, the contents of a file are transferred to the database, so it is particularly important to select the correct target database before carrying out the operation. Check the file name and format, and ensure that you are actually modifying the database you intend to.
Using phpMyAdmin on a cPanel hosting account is part of managing your hosting. Selecting the correct database and taking a backup beforehand is important when importing data, just as it is when making manual changes. You can view the operations related to database management tools via the cPanel interface.
How you access phpMyAdmin depends on where the database is running. In a local development environment, the tool may be linked to the server package running on your computer. On a live website hosting account, you typically access it via the provider’s control panel. The two environments may use separate databases, so always check which one you are logged into before searching for or modifying data.
The cPanel web hosting control panel is not a database management system. This is where you can access the tools related to your hosting account, including phpMyAdmin. Once logged in, select the database management option, then check that you have opened the interface for the correct hosting account and database. The cPanel hosting guide demonstrates this hosting management environment.
A basic understanding of phpMyAdmin is only really helpful if you proceed with care once you’ve logged in. First, check the name of the database, and only then open a table. If your hosting account includes multiple websites or databases, don’t assume that the first database listed is the correct one. By selecting the correct target, you can prevent accidental actions.
First, check that you have logged in to the correct hosting control panel and that the website’s database you wish to manage is associated with that account. If the phpMyAdmin menu item is missing, or if you see a permissions error when logging in, do not try to access another database at random. The exact wording of the error message can help you determine whether the issue is related to access or selection.
If you have a hosting-related query, it may be helpful to browse the guides in the hosting knowledge base. Look for instructions on cPanel, databases or accessing phpMyAdmin. If the interface opens but you cannot see the database you are expecting, check that you are viewing the correct hosting account and that the logged-in user has access to the database.
Once you have logged in, stick to viewing mode at first, and only carry out operations on an authenticated database. If you would like to find out more about cPanel hosting management, learn how cPanel hosting works.
The basics of phpMyAdmin become truly useful when you are not only familiar with the interface, but also know when it is sufficient to simply view the data and when it is necessary to make changes. Start with low-risk checks and plan every modification in advance. This way, managing your website’s database remains more transparent.
The right hosting environment is also a key part of running a website. aWh has over 10 years’ experience in the web hosting industry, and its cPanel hosting is based on NVMe storage. Familiarising yourself with the technical background and the control panel is useful when you’re choosing a hosting provider or want to gain a better understanding of your existing environment.
If you’d like to find out how cPanel hosting works and what it can do, take a look at the details of our cPanel hosting.
No. phpMyAdmin is a management tool accessible via a web browser, whilst the database is a separate system in which the website’s data is stored. For example, if phpMyAdmin does not open, the website itself and the database may still be functioning. The reverse can also occur: the management interface may be accessible, but the website’s database connection may be faulty. Examining the two systems separately can help narrow down the possible cause of the problem.
Yes, for basic browsing and searching, you generally don’t need to program or write SQL code. For example, you can open a table in the interface and view the values stored within it. However, when making changes, you must proceed with caution, even if you are only using graphical controls. To get to grips with the basics of phpMyAdmin, start by viewing the data, and only change fields whose purpose you fully understand.
Not necessarily. Where you find it depends on your hosting control panel and its settings. In a cPanel environment, you will typically find it amongst the database-related tools after logging into cPanel. On other control panels, the name or location of the menu item may differ. If you manage multiple websites, check that you are in the account associated with the correct hosting plan before selecting a database.
Technically, it may be possible, but this is not the recommended first step. WordPress does not store passwords as plain text, so entering an arbitrary value directly may not necessarily work and could cause access issues. If you can log in to the admin panel, use the password reset option there. If not, try WordPress’s official password recovery process first.
Do not make any further changes; first establish from which table the data was deleted and when. Check whether a backup of the relevant database taken before the deletion is available. The method of restoration depends on the contents of the backup and your hosting settings. Do not import a full backup at random, as this may also affect data that has been generated since then. Keep a record of the details of the error.
Where possible, avoid managing databases from public, untrusted networks, and in particular, do not make any changes. On such networks, it is more difficult to assess how secure the connection is, so choose a trusted, password-protected network for database management. Check that the login page uses an HTTPS connection, do not save your password on a shared device, and log out at the end of your session, then close the browser window.
You can use the import function to load the contents of a data file into the database. Such files may include, for example, an SQL backup or a CSV file containing tabular data. Before proceeding, review the data contained in the file and check the selected target database. An SQL file may also modify existing tables or records, so do not start the import based solely on the file name.
]]>It isn’t always clear what needs to be changed in the wp-config.php file, or where the log is located. In this guide, we’ll walk you through, step by step, how to safely configure WP_DEBUG and WP_DEBUG_LOG, how to locate the debug.log file, and how to interpret the entries. We’ll also show you when it’s worth checking your hosting provider’s PHP error log, for example if WordPress won’t even start up. Finally, we’ll go through how to disable debugging and why it’s important to remove the log file from your live site. Debug mode doesn’t fix the error, but it helps you find its source.
WP_DEBUG is one of WordPress’s PHP constants. When enabled, debugging information becomes available, helping you to understand what is happening whilst the website is running. WordPress debug mode is a useful starting point if, following an error, it is unclear whether WordPress, the theme or one of the plugins is affected.
Treat log entries as clues, not as definitive diagnoses. A filename or line of code may indicate where the problem occurred, but not necessarily what caused it. To interpret the message, consider what action preceded the error, whether an update has taken place, and whether the issue can be reproduced.
The aim of troubleshooting is to systematically identify the source of a fault. The basics of troubleshooting also outline this diagnostic process. This guide focuses on WordPress’s own troubleshooting features. Analysing database connection errors and web server logs is a separate topic. Your hosting provider’s PHP error log can be useful if WordPress has not yet reached the stage where it generates its own log.
WP_DEBUG can help identify PHP errors, warnings and messages indicating deprecated functions. These may appear following an update, or when using a particular page, form or administrative action. The file path shown in the log may refer to a plugin, a theme or a WordPress file.
The message alone does not prove that the component mentioned caused the error. It is possible that a plugin’s code is malfunctioning due to an error in another component. Make a note of when the message appeared, what action preceded it, and exactly which file it refers to.
WP_DEBUG makes error information visible, but it does not fix the code. Debugging serves to identify the problem. Fixing the problem is a separate step, which involves modifying the relevant code or settings. You should then check whether the change has resolved the error and has not caused any new operational issues.
Before modifying any files or settings, make a backup so that you can restore the previous state in the event of an error. If a test environment is available, test the changes there rather than directly on the live website used by visitors.
The settings must be specified in the wp-config.php file located in the WordPress root directory. Before making any changes, please back up the file so that you can restore the original version in the event of a typo or incorrect setting.
wp-config.php file or copy it to a secure location.WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY. If any of these are already present, modify their values; do not add any new definitions.WP_DEBUG enables WordPress debug mode. WP_DEBUG_LOG allows debug messages to be written to a file, whilst WP_DEBUG_DISPLAY controls whether these are displayed on the website. On a live site, disable on-screen display. You can also disable this using the display_errors PHP setting.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
This configuration logs errors but does not display them to visitors. The Official WordPress Troubleshooting Guide provides further details on how constants work and on logging.
Before saving, check the semicolons and quotation marks, and ensure that each define() line sets a separate constant. Do not define the same constant twice, as this may cause a warning or unpredictable behaviour. After making changes, try opening both the website and the WordPress admin panel.
When debugging WordPress (in debug mode), logging is a more secure option than displaying detailed PHP messages directly. If the page displays an error after you have saved the configuration file, revert to the original copy and then check the changes again.
If you have enabled logging via the WP_DEBUG_LOG setting, WordPress will, by default, create a debug.log file in the wp-content directory of your installation. Open the WordPress root directory in your hosting provider’s file manager, then navigate to the wp-content folder. Locate the file and either download it or open it in text view. If you have a custom log path, look for it in that location.
Before you go through the posts, make a note of when the error occurred and what action you were performing at the time. For example, make a note if, after updating a plugin, a blank page appears when you open that plugin’s page. Then look for log entries close to that time. Entries both before and after the error may provide important context.
Examine the error type, the path of the affected file and the line number provided. The file name may include an extension or template directory, whilst the line number indicates where in the file the message originated. The time of the error and the file path together help narrow down the investigation. This does not yet prove that the component in question is faulty. A warning or an entry referring to an obsolete function does not necessarily cause the page to crash.
The PHP error logging documentation provides information on how PHP error logging generally works. The WordPress log is not the same as the web server logs. This section focuses on interpreting the debug.log file; a detailed analysis of the server logs is a separate topic.
Compare the time of the error with any recent plugin or theme modifications, updates and configuration changes. If the log contains the path to a plugin, note whether the error occurred after it was updated or activated. The component named in the file may be involved, but a log entry on its own does not prove a cause-and-effect relationship.
Test your hypothesis using a controlled test, preferably in a test environment, and make only one change at a time. This will allow you to determine whether the symptom is related to that particular change. When debugging WordPress (in debug mode), compare the log entries with the reproducible behaviour; do not draw definitive conclusions from a single line of code.
The log may contain useful technical data, paths and details revealing information about the server environment. You should therefore not display PHP messages to visitors on a live website. Set WP_DEBUG_DISPLAY to false and log errors to a file. If a test environment is available, trigger the error there; this way, you are less likely to disrupt visitors’ use of the website.
Follow these steps, and at the end of the test, reset the debugging settings:
Make a note of the component name, the full error message and the circumstances in which the error occurred. Compare these with any recent changes, but do not treat the file name as evidence in itself. If a test environment is available, use it to check whether disabling or updating the specified plugin or theme alters the behaviour. Do not delete or overwrite code based on a single log entry.
Keep the on-screen error display switched off even whilst the diagnosis is taking place. Do not copy the contents of the log to a public forum or any platform where anyone can access it. If you need to share an extract, first remove any personal details or information that could identify the environment, such as full paths. After the investigation, check whether you still need the log, and do not allow entries to continue accumulating on the live website.
When disabling WordPress debug mode, check your website and the admin panel, then ensure that debug mode is switched off. For further information on hosting and WordPress settings, the aWh knowledge base is also a useful starting point.
When you’ve finished troubleshooting, don’t just check whether the error message has disappeared. Restore the temporary settings, remove the log file from the live website, and then test the affected function again. This ensures that the data used for diagnostics does not remain accessible unnecessarily, and also allows you to check whether the website has returned to normal operation.
wp-config.php file. Make a backup of it, then look for the constants added for debugging.WP_DEBUG to false. Also check the settings for WP_DEBUG_LOG and WP_DEBUG_DISPLAY to ensure that logging or on-screen display is not left active.debug.log file from the live site so that its contents do not remain there unnecessarily.Check that no PHP errors or technical warnings are displayed on the website. Review the modified configuration again, paying particular attention to the values of constants and any duplicate definitions. Then test the previously faulty function, such as the login process or the loading of the affected page. WP_DEBUG aids diagnosis, but does not in itself guarantee that the error will be resolved.
If you find traces in the log file that are more likely related to the runtime environment, separate your WordPress settings from the hosting environment. In this case, the next step should be to investigate the hosting environment, rather than modifying WordPress files at random. A detailed analysis of server-side logs requires a separate investigation. For aWh’s cPanel hosting plans, the location of the PHP error log and how WordPress writes the log to a location that is not accessible via the web are explained in the knowledge base article on debug mode.
The aWh WordPress Hosting plan comes with WordPress pre-installed, whilst the WordPress Toolkit Deluxe assists with managing WordPress. These are tools to aid operation; they are not automatic error-correction tools. For further guidance on settings, the articles in the knowledge base can provide a practical starting point. Once you have completed the WordPress debugging process (debug mode), please also check that the site is functioning correctly by testing it with actual user scenarios.
WordPress debug mode is a useful troubleshooting tool, but only keep it enabled for as long as you need the log entries. Once you’ve switched it off, check that the site is working properly and consider how you can prevent a future update or change from causing unexpected disruption. Consistent testing can help you pinpoint the cause of any further errors more quickly.
The PHP version is also part of the WordPress operating environment. With the choice of PHP versions available in the hosting plans, you can tailor the environment to your website’s requirements. When changing the settings, make a note of the current version and the components affected. This will make it easier later on to compare the configuration that works with the one that causes errors.
It is worth briefly documenting the results of your troubleshooting. Note down which action triggered the error, the circumstances under which it occurred, and which change caused the behaviour to change. This record may later help you to distinguish between the effects of your WordPress settings and those of the hosting environment.
Take a look at aWh’s WordPress hosting solutions and choose the environment that best suits your website’s operational needs. Thorough debugging and secure configuration provide a solid foundation for more reliable WordPress operation.
The default WordPress admin interface does not have a built-in toggle for debug mode. This setting typically needs to be configured in the wp-config.php file, provided you have the necessary file access rights. Some plugins may offer their own control panel, but these are separate tools and not part of WordPress’s core functionality. If you are unable to edit the configuration file, please ask your website administrator for help.
Not necessarily. The extension name mentioned in the error message may indicate that the error occurred there, but it does not prove that the component itself is responsible. It may be, for example, that a plugin is processing incorrect data passed on by another plugin. Make a note of the function concerned and the file shown in the log, then test it in a development environment to see if the symptom changes when the component is disabled.
A notice is usually an informative message about how the code works, and does not necessarily cause the page to stop working on its own. An deprecated message warns that the code is using a PHP function or solution that has been marked as obsolete. Find out which file it relates to, then check whether it appears at the same time as an actual error on the website. The warning alone does not mean that the page is malfunctioning.
Yes, debugging can affect performance, particularly if a large number of messages are generated and need to be continuously written to a file. Displaying these messages on screen can also impair the visitor experience if technical messages appear on the page. On a live website, therefore, only use debugging for the duration of the necessary investigation, and switch it off once it is no longer required.
Yes, but with multi-site WordPress installations, bear in mind that the wp-config.php file manages the configuration for the entire installation. The WP_DEBUG setting specified within it therefore typically applies to the whole network, not just a single sub-site. When analysing log entries, make a note of which sub-site the error occurred on and what action was being performed. Separate installations have their own configuration files.
The file may be missing for several reasons. Check that WP_DEBUG is enabled, then trigger an action that generates a log message. Logging may fail if WordPress is unable to write to the target directory, or if the log path is set to a custom value. If the system crashes before WordPress even starts up, the error will not necessarily be recorded in this file.
No. Debugging WordPress primarily provides information about server-side PHP behaviour. Using your browser’s developer console, you can examine JavaScript errors, network requests and how the page is rendered in the browser, amongst other things. For example, if a button isn’t responding, the console may provide a clue; if a PHP process fails whilst the page is loading, the WordPress log may be more useful.
]]>It is not always clear which deployment method is suitable for a VPS, or how to protect the credentials associated with your workflows. In this guide, we walk you through preparing your VPS, using Docker and Docker Compose, setting up persistent storage, and the key steps for configuring your domain and HTTPS. We’ll also show you how to secure access to the platform and how to plan for backups and updates.
The aim is to set up an n8n environment that you can understand and maintain, and which you can then develop further as your needs grow. These steps will help you assess the requirements for running a VPS and choose a solution suitable for testing or long-term use.
n8n is an automation tool that can be used to set up workflows and connect applications. For example, submitting a form can trigger data processing, send a notification and then record data in another system. The ‘What is n8n?’ summary provides background information on the tool’s purpose and how it works.
When self-hosted, n8n runs on a server that you manage yourself. On a VPS, this means you have access to the virtual machine and are responsible for installing, configuring, updating and performing backups for the application. With Docker Compose, service settings can be organised in a single configuration file. However, ensuring secure access and reliable operation remains an operational responsibility.
Installing an n8n VPS is therefore not merely a technical step. You also need to consider how much control you want over the environment and how much time you can devote to maintenance. A KVM VPS provides independent access to the virtual server, allowing you to tailor the settings to your own requirements. aWh’s KVM VPS solution is built on NVMe SSD storage and redundant storage, and offers DDoS protection.
Who is it suitable for? Running n8n on a VPS may be suitable for those who wish to retain control over the server environment and configuration, and who are prepared to manage the application, access rights, updates and backups themselves. If you prefer a ready-to-use, managed service, you should consider whether you are willing to take on regular operational tasks.
With a managed cloud service, the provider manages part of the background infrastructure, so you may have fewer server management tasks. With your own VPS, you play a greater role in configuring the environment, which means you bear more responsibility. You’ll need to plan who has access to the n8n interface, when to install updates and how they are carried out, as well as how backups are created and restored. Greater control does not, in itself, automatically translate into data protection or cost benefits.
Having your own instance can be useful if you want to automate regularly recurring processes. For example, a new prospect’s details can be entered into a spreadsheet, n8n can notify the team, and then forward the information to another application. A few simple workflows may be sufficient for testing purposes. For business-critical, continuous operations, you should also plan your backup and update procedures in advance. Resource requirements depend on the complexity of the workflows, the number of concurrent runs and the data processing load.
In an n8n VPS environment, it is advisable to manage the application, the data and public web access separately. The VPS provides the runtime environment; n8n runs in a Docker container; the mounted volume stores the application’s data; and the domain points to the VPS. The reverse proxy receives web requests and forwards them to the appropriate internal service.
Data streams and external access points:
Browser or external service → domain DNS settings → HTTPS connection → reverse proxy → n8n container
n8n container ↔ persistent volume mounted on a VPS
n8n container → external applications and services
Web requests arrive via the domain, and the proxy forwards them to n8n. If the proxy handles the traffic, there is no need to make n8n’s internal port directly accessible to the public. When designing external access points, take into account the admin interface and any webhooks that receive requests from external systems. Restrict access to internal services to only the necessary connections.
Docker Compose organises the related services into a single configuration file. This file can specify the n8n container image, the environment variables required for startup and the mounting of persistent volumes. If a separate proxy or database is also running, their settings can be included in the same configuration. This makes the entire setup more transparent and changes easier to track. Please check the syntax against the official Docker Compose documentation and the current n8n installation guide.
Replacing or recreating a container does not automatically preserve the data stored within it. You must therefore associate a separate volume with the n8n data directory in the Compose file. The volume stores the data on the VPS independently of the container’s lifecycle, but it is not a substitute for a separate backup. Set the read permissions for the files carefully and protect any confidential environment variables.
The domain’s DNS record directs requests to the VPS address. The proxy receives web traffic coming to the domain and then forwards it to n8n’s internal address. When using HTTPS, the proxy and certificate settings must also be configured to work together. The external URL for n8n must use this same full, encrypted address; otherwise, links or webhook addresses created within the interface may be incorrect.
aWh’s KVM VPS environment provides access to standalone virtual server installations. The overall architecture remains clearer if you document the roles of the domain, proxy, container and data storage separately. This makes it easier to identify the affected component in the event of a configuration error or change.
When choosing an installation method, don’t just consider which one can be set up quickly. It’s also important to consider how much control you want over the configuration, and whether you’re prepared to carry out regular maintenance. The comparison below will help you choose the approach that best suits your needs.
| How to get there | Control and customisation | Maintenance requirements | Who might find this useful? |
|---|---|---|---|
| Docker Compose | Containers, variables, networks and persistent volumes can be configured. | You manage the configuration, updates, backups and access rights. | For those who want to understand and customise the entire architecture on their own VPS. |
| Direct installation | The server environment is set up directly on the operating system. | The user is responsible for maintaining the application and its dependencies, such as the runtime environment. | For technical users who have a specific reason for operating without containers. |
| Pre-installed solution | Part of the initial setup can be carried out by the solution provider. | Installation may be simpler, but the available settings depend on the service. | For those who want to minimise the amount of initial server configuration required. |
The table shows general guidelines and is no substitute for checking the latest n8n documentation. Details and support for direct installation may vary, so please consult the official n8n guide before using it in a production environment. aWh offers AMD Epyc KVM VPS servers on which you can install and configure n8n.
Docker Compose provides a particularly clear framework if, in addition to n8n, you are running other interconnected services, such as a reverse proxy or a database. The settings for these services can be managed, started and modified all in one place. This method is suitable for you if you wish to retain control over configuration, data storage and the update process. You can read more about how KVM-based virtual machines work in the description of the KVM VPS solution.
If you have little experience in managing servers, a managed solution can reduce the initial set-up tasks. However, this does not mean that every configuration, update or data management decision is automatically made on your behalf. Responsibilities depend on the solution you choose, so please review the installation guide and the latest n8n documentation together.
Choose your VPS resources based on your expected workload. Take into account the complexity of your workflows, the number of application connections, concurrent processes and the volume of data processed. Testing and business-critical, continuous use may have different requirements. aWh’s range of KVM VPS plans can serve as a starting point for planning your n8n VPS deployment.
The example below is based on an Ubuntu-based VPS. Commands and configuration keys may vary depending on the operating system, Docker release and n8n version used. Before installation, please check the latest n8n, Docker and operating system documentation. Do not copy environment variables or the container image version without checking them first.
Install the Docker Engine and the Docker Compose plugin following the current guide for your distribution. Then check that both tools are available. The version commands will show the installed version. docker –version
docker compose version
Create a separate directory for the installation files. This command creates the directory and then changes to it.mkdir -p ~/n8n && cd ~/n8n
Create a compose.yaml file here. For the service, specify the official n8n container image, preferably with a verified, fixed version tag. Set the persistent volume to the path /home/node/.n8n, as well as the environment variables N8N_HOST, N8N_PROTOCOL=https and WEBHOOK_URL to match your domain. If the reverse proxy is running on the same VPS, make internal port 5678 accessible only to the local address. Check the variable names against the current n8n documentation.
Start the service described in the Compose file from the installation directory. This command runs the container in the background. docker compose up -d
Next, check the logs. Look for start-up errors, missing variables and any issues relating to the database or volume.
docker compose logs -f n8n
After making any configuration changes, restart the service using the same Compose file. If the service name is different, use the name specified in your own file.
docker compose restart n8n
In the domain’s DNS settings, point the domain name you are using to the VPS’s public IP address. The reverse proxy should forward incoming requests to n8n’s local address and port, and handle the HTTPS certificate. Also check that n8n’s external address points to the full HTTPS domain. The specific proxy configuration depends on the software you are using.
Open the n8n interface on the domain, log in, then create a simple test workflow. Run it and save it, then check that it remains intact after reloading. If you connect an external service to it, check the authentication and the connection result. Finally, check the logs to see if any errors occurred during the test.
For a standalone server environment, aWh’s KVM VPS solution provides a virtual server on which you can plan your n8n installation to suit your own requirements.
Running n8n independently remains straightforward if, alongside day-to-day use, there is a clear procedure in place for managing access, backups and updates. Make a note of where each setting is located, who is authorised to change it, and what checks you carry out after making a change. This way, in the event of an error, you can more easily determine whether the problem is caused by the application, the VPS configuration or an external connection.
Keep your VPS administrator access and your n8n dashboard accounts separate. Use unique, strong credentials for both, and regularly review who has access. Treat any external service credentials stored in n8n as confidential. Only authorised users should have access to the Compose file and files containing environment variables.
Adjust the frequency of backups to suit the rate of data changes and the potential consequences of data loss. There is no single interval that applies to every installation. In your operational plan, also set out how you will restore n8n and what checks you will carry out to ensure that authentication details and workflows are functional following restoration.
The aWh AMD Epyc KVM VPS may be suitable if you wish to install and configure n8n with direct server access. When selecting VPS resources, do not base your decision solely on current usage: take into account the complexity of your workflows, concurrent processes, related services and the volume of data processed. If the workload changes, review from time to time whether the capacity is sufficient for actual operations.
The KVM VPS guide can help you understand the virtual server environment. However, choosing a VPS is only part of planning your infrastructure; the installation, configuration and maintenance of n8n must still be tailored to your operational plan. For technical details, take a look at aWh’s AMD Epyc KVM VPS solution.
Before launching production workflows, appoint someone to be responsible for monitoring changes and any errors that may arise. Consider which automated processes, if they fail, require immediate intervention, and what checks should be put in place to indicate if a process is not producing the expected result. Incorporate these considerations into your operations plan right from the start.
The next step in installing n8n on a VPS is to assess whether self-hosting is suited to your technical capabilities and automation goals. Take a look at aWh’s AMD Epyc KVM VPS solution and use it to design your n8n environment to suit your own needs.
Not necessarily. The VPS must support your chosen operating system and installation method. When using Docker, the Docker runtime requirements must also be met. Resource requirements are influenced by the number and complexity of workflows, concurrent processes and the volume of data. Different capacities may be required for testing and ongoing business use, so you should base your decision on the expected workload.
Docker Compose can be a straightforward solution if you wish to manage n8n alongside other services. With a direct installation, the application’s runtime environment and its updates are more closely tied to the VPS operating system. Choose the approach that best suits your configuration and maintenance practices. Before doing so, check the latest n8n installation guide and the requirements for the chosen method.
Not necessarily; it may also be accessible via the n8n server address. With a domain, you can use a web address that is easier to remember, and it is simpler to configure the HTTPS certificate, the reverse proxy and the n8n external URL. The DNS record must point to your VPS address. If you’d like your own address, you can find out more about aWh’s domain registration options.
Secure the interface with HTTPS and unique, strong login credentials, and restrict administrator access. Keep the SSH access used for the server separate from your n8n user accounts. Do not store passwords or other confidential settings in publicly accessible files or code repositories. Keep the system up to date and ensure that users have only been granted the permissions necessary for their work.
Yes, provided that the n8n data directory is managed by a properly mounted persistent volume stored outside the container. The preservation of workflows depends not only on the reboot, but also on the correct configuration of the volume and the state of the database. After rebooting, log in, check that the workflows are displayed, and then try one out. The volume is not a substitute for a separate data backup.
The choice of database depends on the workload and operational requirements. The default database for n8n is SQLite, whilst PostgreSQL is a common choice for higher-load, production environments due to its scalability. When making your decision, you should also take into account backup, restoration and database maintenance. Always check the supported versions and configuration variables in the latest n8n documentation.
Yes, a Compose-based installation can be updated, but the procedure must be adapted to your configuration and the current n8n guide. Before updating, create a backup of your persistent data and the necessary configuration. Next, review the release notes, then, after making the changes, check the container logs, the login status and the status of any important workflows. Avoid unchecked version changes in a production environment.
To set up your own n8n environment, take a look at aWh’s AMD Epyc KVM VPS solution and choose a server environment suited to your planned workload.
]]>It is worth clarifying in advance who needs to submit the application, what data or documents need to be prepared, and what will happen to the settings associated with the domain. The website, DNS settings and email service are elements that need to be handled separately. Before the transfer, you should therefore plan how the web and email services will remain accessible.
In this article, you’ll find out when a transfer is justified and how it differs from a registrar change. We’ll outline the roles of the transferor and the transferee, as well as the administrative steps required depending on the domain’s status. This will help you plan the process and ensure the continuity of related services more effectively.
The decision depends on whether the domain holder is changing or whether it is just the service provider. If another person or organisation is to become the domain holder in the registry, a transfer is required. If you remain the domain holder but wish to manage the domain through a different registrar, this is known as a registrar change. This distinction determines which procedure needs to be initiated.
Upon transfer, the right to use the domain is transferred from the transferor to another user, and the new user is also listed in the registry. The transaction may be based on an agreement between the parties and does not necessarily have to form part of a sale. For example, an organisation may transfer the domain to another organisation as part of a business agreement, or an individual may decide who should be the domain holder going forward. The procedure may depend on the type of domain and its registration status.
Transferring a domain is not the same as transferring a website. The domain name directs visitors to the relevant internet service, but the website files, web hosting and email are separate elements. The Domain Name System (DNS) links domain names to internet services based on the technical data assigned to them. A change of provider therefore does not, in itself, transfer the website or email accounts. You should plan your DNS settings, hosting and email separately to ensure they continue to point to the correct locations after the transfer.
It is worth initiating a registrar transfer if the domain holder remains the same, but you wish to manage the domain’s administration through a different provider. For example, a business may continue to use its domain in its own name but transfer its maintenance to another registrar. In such cases, no new registrant is entered in the register, so a transfer is not the appropriate procedure.
You can distinguish between the two processes by asking the following question:
If you’d like to get to grips with the basics of domain registration, take a look at the domain registration options. Once you’ve chosen the right service, make sure you also check that your web hosting and email settings remain consistent. This way, you won’t confuse a change in the domain holder with the automatic migration of your website or email.
In the case of .hu domains, changes to user details are not simply a matter of agreement between the parties. Any changes to the registry records must be initiated via the registrar: the registrar receives the request and then forwards it to the registry. The details of the procedure depend on whether the domain is a ‘factor’ domain or an older, document-based registration.
The transferor must be identifiable as the current domain holder. The transferee’s details must correspond to those of the natural or legal person who is to be granted the right of use. In the case of a two-factor authentication process, the code may be sent to the registered email address involved in the process. In cases involving a written application, the transfer is recorded in a declaration by the current user, whilst the new applicant’s details are contained in the domain application submitted to the registrar: for a legal entity, this includes the name, postal address, contact email address and telephone number, tax number or registration number, and authentication details. Before submitting the application, please check the current formal requirements and ensure that all details are correct.
Before a guided or open transfer, a domain protected by a certificate must be switched to two-factor authentication; if this is not done, the transfer will remain a certificate-based transfer. The transfer does not change the domain’s expiry date, so the new user should also bear this date in mind. Before the transfer, check the transferee’s eligibility and the current conditions of the procedure. No further such changes may be initiated for 30 days following a change of registrant or registrar. As procedural requirements may change, please follow the regulations in force at the time of submitting the application.
If, as well as managing your domain, you’d like to look into registration and administration, the aWh domain page outlines the relevant options.
A domain-related transaction may involve several separate changes. The domain holder, the registrar or the hosting provider for the website and email services may change. These changes may occur simultaneously, but none of them automatically follows on from the other. You should therefore plan the administrative and technical transition separately.
Domain transfer therefore involves the transfer of usage rights, not the transfer of the entire online presence in a single step. The domain name, website files, hosting and email service must be handled separately. For example, if a business transfers the right to use a domain, the website may remain on its current hosting service until specific arrangements are made regarding access or migration.
When a domain is sold, the purchaser acquires the right to use the domain, but not automatically the associated website, database or email service. The transfer may take place in return for payment, but the right of use may also be transferred as part of a separate agreement, without any payment. The parties must therefore clarify exactly what is being transferred. The terms of the agreement should not be confused with the administrative procedures for domain registration.
From a practical point of view, it is worth making a separate note of the status of access rights and services associated with the domain. Changes to registration details do not replace the transfer of website files, nor do they automatically grant access to the web hosting account or email inboxes. These matters must be settled separately by the parties concerned.
No. Changes made to the domain registration and DNS settings are two separate matters. The DNS records determine which hosting or email service the domain directs visitors and emails to. If the location of the services remains the same, the steps required may differ from those involved in the migration to a new hosting provider. Before making the change, make a note of your current DNS settings and the accounts affected.
Hosting the website’s files and keeping the site running requires separate hosting, which is a different process from domain registration. The continuity of email accounts and email settings must also be arranged separately. aWh offers both web hosting and email hosting, and with its free migration service, it also helps with the transfer of your existing website and email accounts. The migration is a separate process from the transfer of domain ownership.
A smooth handover depends on more than just the accuracy of the registration details. You should also clarify in advance the responsibilities of the people in charge of the website, the DNS server settings and email. This ensures that a change in the domain holder does not lead to any confusion about who has access to the various services and who carries out the necessary checks.
The transferor should compare the domain name and the user details listed in the registry with their own current details. Please also check that the contact email address is correct, as notifications or requests for approval may be sent to this address during the process. If you find any discrepancies, please clarify which details need to be corrected before proceeding.
The transferee should prepare the applicant’s details and check that they meet the conditions for .hu domains. Together with the transferor, ensure that the same domain name appears in all applications and related agreements. Please submit the necessary declarations and documents in accordance with the procedure in force at the time of processing; do not base your submission on a previous case or a different type of domain.
Before carrying out the registration process, make a note of who has access to the DNS settings, web hosting and email accounts. These may involve different control panels and access levels. Transferring a domain does not, in itself, transfer the website files, move email accounts or automatically change the provider of the associated services.
If your website or email service is being moved to another provider, plan the migration process carefully. Agree on who will amend the DNS settings, who will check that the website is accessible, and who will test sending and receiving emails. Transfer access details securely, then review who needs to retain access to the accounts. Finally, check that the domain points to the correct website and that email is working.
It is worth taking a separate look at the functions of domains and hosting. Take a look at aWh’s domain registration options, as well as its web hosting and email solutions, if you’d like to organise the management of these related services too.
Once the registration change has been finalised, please check the domain holder’s details and the functionality of the associated services separately. A successful transfer indicates that the domain holder has changed, but does not in itself confirm that the DNS settings, the website and email services are also in the desired state. If these are also affected by the change, a technical check should be the next step in the process.
Start by checking whether the new user’s details are actually listed in the registry and whether the domain name exactly matches the name provided. Next, clarify who manages the DNS server settings. Check that the domain points to the desired website and that the email settings are linked to the correct service.
If you are changing your hosting or email service, check the availability of your website and your email service separately. Test important pages and forms, and for email, try sending and receiving messages. A functioning homepage does not guarantee that email is working properly. If you do not manage the settings yourself, designate someone to carry out the tests.
After a domain transfer, it is also important to organise access rights. You should only amend or revoke the previous user’s access rights once you have clarified which accounts are still required for operations. By ensuring a secure handover of access rights and reviewing unnecessary permissions, you can minimise administrative uncertainty later on.
If, after completing the necessary formalities, you wish to register a new domain or manage multiple domains, aWh offers registration for a range of domain extensions. Registration of .hu domains takes place with immediate activation. This service applies to the registration of new domains, not to the transfer of existing domains.
aWh’s automated administration approach helps to ensure the domain registration process is managed efficiently. When selecting web hosting and email services associated with your domain, please bear in mind that whilst these are linked, they may require separate configurations.
If you’re looking to register a domain, take a look at aWh’s domain solutions and choose the next step that best suits your needs.
Transferring a domain is a good opportunity to review not only the registration details but also the management of the associated services. Decide who is responsible for the DNS settings, the website and email, then securely transfer the necessary access rights. This will ensure that it remains clear in future who is authorised to make changes and who is responsible for monitoring the services.
If you need a new domain, aWh offers registration for a range of domain extensions. Registration of .hu domains is activated immediately. This registration service is separate from the transfer of usage rights. By choosing the right domain and clarifying responsibilities, you can make the management of your online presence more transparent.
Take a look at aWh’s domain registration options and choose the next step that best suits your needs.
In the case of a transfer, the domain holder changes, whilst in the case of a registrar change, the provider managing the domain changes. Before submitting your request, please clarify who is currently listed as the domain holder and who the new domain holder will be. If you only wish to change providers, please do not confuse this request with a change of domain holder, as these are different processes.
Yes, the right to use a domain can be transferred without any consideration. The parties must clarify whether the transfer applies only to the domain, or whether it also covers other access rights, content and services. These are listed separately so that it remains clear at a later date which accounts and data the transferee will have access to. The payment of consideration does not replace the registration formalities.
The transfer does not change the expiry date of the .hu domain. The transferee should therefore continue to keep track of the original expiry date even after the registration change, and clarify who will be responsible for monitoring notifications relating to the maintenance of the domain. This is particularly important if the contact address or the person responsible for administration also changes.
No. Transferring the use of a domain does not grant access to the hosting control panel or email accounts. If these are also part of the transfer, please make separate arrangements regarding the accounts, access rights and data management. With regard to email, also clarify whether it is necessary to retain previous messages. Transfer access details securely and review previous access rights.
The documents required depend on the domain transfer procedure. For a ‘Faktoros’ domain, the current domain holder’s ‘Faktoros’ approval or an authorisation code is required. For domains protected by a deed, a statement from the current domain holder regarding the transfer, set out in a private or public deed with full probative force, as well as the new applicant’s domain application in accordance with DRSZ 1.2.2. Before submitting your application, please review the current requirements and check that the domain name and the parties’ details are correct.
The duration of the process depends on the domain registration procedure and the processing of the application; therefore, it is not possible to provide a time estimate that applies to all cases. Missing approvals or the need to clarify details may require further steps. Please plan the process so that there is time to rectify any omissions and to check the related web services.
After the registration transfer, please check that the user details are displayed correctly and that the new contact person can access the account used to manage the registration. Review the access rights of the previous administrator and retain only those that are necessary for continued operation. The domain holder will change; however, please check the DNS settings, the website and the email separately.
]]>A redirect loop occurs when two or more rules successively send the browser from one address to another, and then back to the previous one. This can be caused, for example, by data stored in the browser, WordPress URL settings, a plugin, the .htaccess file or the HTTPS configuration. Making changes at random may further impair the site’s accessibility, so you should first isolate the possible causes.
In this guide, we’ll proceed in a logical order: first, we’ll check your browser, then your WordPress settings, plugins and redirect rules. We’ll also show you when it’s appropriate to request a hosting or server-side investigation, so that you can resolve the issue in a targeted manner and avoid unnecessary changes.
The ‘too many redirects’ error appears when, upon opening a web address, the browser encounters redirects that do not lead to a final page. The message indicates that the request has failed, but does not in itself prove that the browser is faulty or that the website’s entire system has crashed. The cause may be local, such as a stored cookie, but is often to be found in the website’s or server’s settings.
A redirect loop is caused by repeated changes of address: a request is sent from one URL to another, which then redirects back to the original address. A common example is when the system attempts to redirect the visitor to both the ‘www’ and non-‘www’ versions of the address at the same time. This can happen on any website, not just WordPress sites.
Let’s assume that the URL http://pelda.hu redirects to HTTPS, whilst the rule for https://pelda.hu requests the version with ‘www’, where another setting then redirects the browser to the URL without ‘www’. The request thus keeps being sent to different URLs over and over again. The browser does not receive the final page content, so after a while it stops trying and displays an error message. The maximum number of redirects allowed may vary depending on the browser.
To troubleshoot the issue, isolate the layers that may contain settings affecting redirection or the request path. The same symptom may originate from several sources, so the browser message alone does not identify the root cause.
The redirect set up on the hosting account is included in the server’s response, whilst a redirect initiated by the website itself may be triggered, for example, by WordPress or a plugin. Both layers can function correctly on their own, but together they can create a loop. It is important to use a consistent URL format: whether it is HTTP or HTTPS, or the ‘www’ or root domain form, you must use the same one consistently across all layers of the configuration.
WordPress can manage your website’s address and redirects in several places. If these settings differ from the rules specified by your hosting provider or a plugin, the system may send conflicting instructions to the browser. The ‘too many redirects’ error does not necessarily stem from a single incorrect setting: two rules operating independently of one another can also create a loop when combined.
Once you’ve accessed the admin panel, you can check these two addresses on the Settings → General page. The ‘WordPress Address (URL)’ specifies where WordPress is installed, whilst the ‘Site Address (URL)’ determines the address at which the site is accessible to visitors. Ensure that the protocol and domain format are consistent across both fields.
For example, if the WordPress address is https://pelda.hu, but the website address is http://www.pelda.hu, the system is using a different protocol and www version. If another setting overwrites either of these, a loop may occur. First, make a note of the current values, and only change them once you have determined which version of the address the website should use.
If you are unable to log in to the administration panel, do not modify the addresses stored in the database without first checking them. An incorrect value may further impair accessibility. In such cases, please make a backup first, or request hosting-level assistance to check the settings.
The switch to HTTPS can be enforced by several layers: WordPress, a security or redirect management plugin, or the web server. If, for example, a plugin redirects to HTTPS whilst another rule redirects the request back to the original HTTP address, a redirect loop may occur. Check which settings handle HTTPS, and do not enable multiple redirects with the same function at the same time.
Exercise caution when testing plugins. Make a backup first, then disable just one plugin at a time – one that handles redirects or HTTPS enforcement – on a trial basis. Check the site after every change; this makes it easier to identify the faulty setting. Ensure that the change is reversible; do not delete any extensions or configuration files solely for the purpose of testing.
If the URLs are consistent but the error persists, checking your WordPress logs may be the next step. A guide on troubleshooting WordPress by enabling WP_DEBUG mode can help you understand how to investigate PHP errors, but logging alone will not fix the redirect. Do not make the logs publicly accessible, as they may contain sensitive technical data. If you wish to review your WordPress operating environment, the WordPress hosting guide may provide further guidance.
If you are unable to carry out the investigation because the admin panel is unavailable, or if the error persists even after checking the plugins, please also review the server-side settings. A more detailed guide on WordPress and hosting may help you decide at which level of settings to continue your investigation.
You can narrow down the source of the ‘too many redirects’ error through targeted testing. First, check whether the issue only occurs in one browser and on one device, or whether it can be reproduced in other environments. Comparing the results across multiple browsers and devices will help you narrow down the location of the error. This will not automatically identify the faulty configuration, but it will show whether it is worth investigating the local browser settings or the website itself.
| Layer examined | Characteristic sign | What should you check? |
|---|---|---|
| Browser | The page loads in another browser or in a private window. | The website’s cookies and your browser’s local data. |
| WordPress | The error occurs in several browsers whilst the WordPress settings have been changed. | Website addresses, as well as plugins that handle redirects or HTTPS. |
| Server | The site cannot be accessed from various devices, and the server sends a redirect for every request. | The redirect rules applicable to the hosting account and the web server settings. |
| Domains and DNS | URLs with and without ‘www’ behave differently, or do not point to the same service. | The DNS records associated with the domain and the current hosting service. |
Open the same web address in a different browser or in an incognito window. If it loads there, clear the cookies for the website in question in your original browser, then try again. This test will not alter the website’s settings. If the page does not open in an incognito window either, or if you encounter the same error in multiple browsers, proceed to check WordPress and the server settings.
Try opening the www and root domain addresses separately, then check whether both lead to the same intended version of the address. DNS records direct the domain to the correct destination, but redirection rules typically operate on the web server or the website itself. Do not modify the DNS simply because a record is recommended as a solution in the documentation for another platform.
Different services use different DNS settings and record values. Please check the records associated with your domain and hosting service against the relevant documentation. For example, do not copy Webflow’s A or CNAME records into the configuration of another service: platform-specific values may point to a different destination and cause further access errors. In a cPanel environment, the cPanel hosting information is directly relevant to this check when reviewing your hosting settings.
Before making any changes, note down exactly when and at which address the error occurs. This way, after each modification, you can use the same test to check whether the behaviour has changed. Do not change several settings at once: if the error disappears or worsens, it will be easier to identify which change caused it.
In the admin panel, you’ll find the ‘WordPress Address’ and ‘Site Address’ fields on the ‘Settings → General’ page. Use the same protocol and domain format for both. When testing plugins, make a backup, disable a single redirect management plugin, then repeat the same loading test. If the result remains the same, revert to the original settings before changing any other settings.
A server-side redirect may be correct in itself, but it may conflict with a rule in WordPress or a plugin. Check the destination URL set on the hosting account and the final URL version used in WordPress. Do not apply a specific DNS record or .htaccess rule without understanding how the web server and hosting account work.
If your website stops working properly after making a change, restore the backup of the original file or setting, then check the website again. For cPanel hosting, you can also review the settings associated with your hosting account via the cPanel control panel. If the error is related to server-side rules and the change cannot be safely reverted, please request support at the hosting level.
If the website displays the same error across multiple browsers and devices, the problem is unlikely to be caused solely by your browser’s local data. An investigation at the hosting level is also warranted if the request repeatedly encounters server-side redirects, the WordPress admin panel is inaccessible, or the error began after changes were made to the hosting settings. Do not attempt to add new rules at random, as this may make it even more difficult to identify the cause of the error.
Requesting assistance is more effective if the operating environment and any checks carried out to date are accurately documented. aWh’s knowledge base can also provide guidance on reviewing hosting-related settings before submitting a fault report.
Please describe the error in such a way that the technician investigating the issue can reproduce the problem. Provide the exact URL of the page in question, the error message displayed in the browser, and details of when and under what circumstances you encountered the problem. Please also indicate whether the issue occurs in the same way when using a different browser or device.
If you have restored a file or configuration from a backup, please mention this as well. A chronological record of changes helps to distinguish between redirects caused by WordPress’s operation and those resulting from the hosting provider’s rules. Accurate data reduces unnecessary troubleshooting and makes server-side troubleshooting more targeted.
Consistency in website and hosting settings makes it easier to identify errors. If the address used in WordPress, HTTPS handling and hosting redirects all follow the same definitive domain version, there is less chance of conflicting rules. When choosing a WordPress operating environment, aWh’s WordPress Hosting service provides pre-installed WordPress and the WordPress Toolkit Deluxe management tool.
aWh’s professional support team is available 24 hours a day. If the ‘too many redirects’ error occurs in multiple environments, or if your server settings need to be checked, please request hosting-level support. Discover aWh’s web hosting solutions and choose the environment that best suits your website’s operational needs.
Once the error has been resolved, document the changes you have made and keep a backup of the working configuration. This will make it easier to compare the new state with the previous one during any future updates or reconfigurations. If the ‘too many redirects’ error reoccurs, your notes will help you identify more quickly which change caused the problem.
For stable operation, it is also important that the settings for WordPress, the domain and the hosting are properly aligned. With over 10 years’ experience in the web hosting industry, aWh offers hosting solutions. When choosing the right environment, take into account your website’s operational requirements and the management options you need.
Take a look at aWh’s web hosting solutions and choose the option that best suits your website. The carefully documented settings and consistent hosting configuration provide a solid foundation for your website to serve its visitors reliably.
This means that the browser is receiving repeated redirects and is unable to open the final address of the requested page. The ‘too many redirects’ error does not, in itself, reveal which setting is causing the problem. For example, a rule redirecting to HTTPS and another rule redirecting back to HTTP may be triggered one after the other. To identify the exact cause, check the settings of the browser, the website and the server separately.
Yes, due to a cookie stored for a website or your browser’s previous state, the error may only appear in your browser. Try opening the same page in an incognito window or in a different browser. If it loads correctly there, clear the cookies for that website and then try again. If the error occurs in multiple browsers and on different devices, it is more likely that the website’s settings need to be investigated further.
You may also be unable to access the admin panel if the WordPress installation URL and the website address provided to visitors use different protocols or domain variants. An HTTPS configuration or redirect plugin may also be causing the issue. If you are unable to log in for this reason, do not edit database values at random. First, back up your files and the database, then check whether any URL or plugin changes have been made previously.
Not necessarily. HTTPS alone will not resolve the issue if the website, the hosting provider or an intermediary service is redirecting requests in different directions. For example, one setting may switch to HTTPS, whilst another redirects the browser back to HTTP. First, determine which layer is handling the redirection, and only modify the relevant setting. Do not disable encryption or website protection as a test.
DNS generally maps the domain name to its corresponding server; it does not carry out the HTTP redirection of the website itself. However, configuring it may still be important if, for example, the ‘www’ and non-‘www’ addresses lead to different servers, where different redirection rules apply. Before checking, please refer to the guide for your domain and hosting. Do not automatically apply A or CNAME records specified for other platforms.
If you experience the same issue in multiple browsers, make a note of the affected URL and the time the error was detected. Check whether the issue affects the homepage, the admin panel or just a subpage. Then review your most recent WordPress and hosting changes. Make a backup before making any changes to files or the database. If you do not have access to server-side redirects, please forward the recorded details to aWh’s support team.
Yes, if the loop is caused by a rule in this file, but .htaccess is not used in all hosting environments. Before editing, check the type of web server and create a backup of the original file. Do not copy and paste generic redirect code simply because it is listed as a solution on another website. Make changes one at a time, then check the homepage and the relevant URL.
]]>The decision is primarily determined by the site’s features and how it is updated. An introductory page, blog or documentation can typically be served using static files. However, in the case of user login, personalised content or database management, a server-side environment may also be required. The static approach can mean simpler operation and a smaller attack surface, but it does not replace the dynamic features required by every project.
This guide explains how a static website differs from its hosting, how the site is generated, updated and published, and what factors to consider when choosing a hosting provider. We compare static hosting, traditional web hosting, cPanel hosting and KVM VPS so that you can find the solution that best suits your project’s operational requirements.
Static web hosting serves pre-generated web files to visitors’ browsers. This definition refers to the method of publication, not to how the site was created. Static web hosting is therefore not the same as the website’s structure or the program used to create it. All three play a distinct role in its operation.
The visitor downloads ready-made HTML, CSS and JavaScript files. HTML provides the structure of the content, CSS determines the appearance, whilst JavaScript can enable behaviour or interaction within the browser. A static page is therefore not necessarily static or devoid of interactivity. It may feature a drop-down menu or a browser-based image gallery, provided that its operation does not require server-side processing for every visitor.
The process consists of three complementary parts. The website’s structure determines the content, page sections and layout. A generator such as Jekyll, Hugo or Astro generates the publishable files from source material and templates. The hosting service stores these and then sends them to the visitor’s browser upon request. The summary on how static websites work also discusses this model, which is based on pre-generated content.
For example, there is no need to compile the content of a page displaying opening hours, service descriptions and contact details separately for each visitor. The browser receives the same pre-prepared version until you publish a new one.
A static solution is suitable for websites whose content can be generated in advance and which do not need to provide a different server-side response for each visitor. It is not the size of the site that is the deciding factor. A large documentation portal can operate statically, whilst even a smaller website may require a dynamic backend if, for example, it manages user accounts.
The static approach is less suitable for projects where user accounts, databases, personalised content or server-side data processing are essential to operation. In such cases, a dynamic application or a structure combining a static site with dynamic features may be required. aWh also offers static hosting for projects wishing to publish static files. Before making your choice, clarify what operations the site needs to perform, then assess the volume of content and hosting requirements accordingly.
The source material created during development is not necessarily what the visitor’s browser loads. Jekyll, Hugo or Astro generate a finished web output based on the project’s content and settings. The generator creates HTML, CSS and JavaScript files from the source files, which can then be published on the hosting service.
The process consists of three distinct tasks: preparing the content and source files, generating the website, and then uploading the finished files to the hosting server. Static website hosting serves the final files, not necessarily the entire directory of the developer’s project.
A development project may contain articles or other content, templates, images, style settings and the source files required for the site to function. The generator organises these according to the selected structure. For example, it inserts the content of an article into the appropriate template, then creates a version of the page that can be displayed in a browser. Jekyll, Hugo and Astro fulfil this conversion role, using different tools and workflows.
Once generation is complete, the files intended for publication will be found in the output folder. These may include:
The source code and the final output are not interchangeable. Generally, you should upload the folder containing the files intended for visitors to your hosting account. The exact folder structure depends on the project’s settings.
Before publishing, identify the location of the generated files, then upload the relevant files to the area of your hosting account designated for web content. Next, configure the domain so that visitor requests are directed to the correct hosting account. Domain registration may also form part of the process when managing your domain.
Editing the content alone does not update a page that has already been published. The new version must first be regenerated and then published. This can be done manually or as part of another development workflow, depending on the tools used and how the hosting is managed.
The choice depends on how the website’s content is generated and what tasks the server needs to perform. A static solution serves pre-generated files, whilst a dynamic website may also perform server-side processing upon request. The comparison below highlights general operational differences, rather than the technical specifications of individual hosting plans.
Criteria
Static website
Dynamic website
How it works
Serving pre-generated web files.
The server can process or compile the content on request.
Database requirements
A database is not usually required for basic operation.
Features such as account management may require a database.
Server-side features
The content is typically not generated by server-side program logic in response to a visitor’s request.
Functions based on server-side processing may also work.
Update process
Modify, regenerate, then publish the new files.
Depending on the application, the content management system can update the data directly.
If the content of the site can be pre-generated and there is no need to provide a different server-side response to each visitor, a static structure may be suitable. Examples include a professional portfolio, a product showcase or documentation, where the pages display pre-defined information. With a simpler operational structure, the server has less application logic to handle, but the published files still need to be protected and kept up to date.
You should also take into account the update process. Modifying a new article or product description in a project that uses a generator may involve editing steps, regenerating the content and uploading files. This is a process that can be planned effectively, but it is not the same as when content saved in a control panel appears immediately.
A dynamic environment may be required for user accounts, database operations, personalised pages or server-side business logic. It is the functions that determine what kind of runtime environment is needed, not the number of subpages alone. Dynamic elements can also be combined with static pages if the project’s structure supports this.
Depending on your management requirements, you might want to consider either cPanel hosting or VPS hosting. cPanel hosting provides a cPanel control panel for managing hosting settings, whilst KVM VPS can offer greater server-side control to those who require their own environment for their applications to run. Dynamic operation raises a number of operational and security considerations, such as application and database maintenance.
Static website hosting is suitable for your project if simply serving the finished files is sufficient. If the site needs to process data or generate content that varies by user, dynamic hosting or a VPS may be more appropriate. When making your decision, take into account the required features and the operational tasks you are able to undertake.
To choose the right hosting plan, first assess how your project works and how content is published. Think about what features your website uses, what types of files you publish, and how often you update the content. Then consider how much storage space you need, what kind of control panel you require, and what security features are essential.
The basic principle is simple: the required server-side functions determine whether static or dynamic hosting is suitable for the project. Static website hosting may be suitable for pre-built files, but if the site requires a database or server-side processing, a different environment may be needed.
Take stock of the types of files you’ve published and any expected changes. A text-based documentation site, an image-heavy portfolio and a page containing downloadable guides may each require different amounts of storage space. The storage requirements for images and documents depend on the number and size of the files. As well as your current files, it is worth taking into account any expected growth. The required capacity can be estimated more accurately based on the project’s files than by using a general threshold value.
Storage capacity is not the same as visitor traffic, and neither of these factors describes the website’s functionality. Storage capacity indicates how much data can be stored, whilst traffic requirements indicate the load under which visitors must be served. A large image gallery may take up a lot of space, whilst not managing user accounts; a smaller website, on the other hand, may require a database and dynamic functionality.
Your update schedule is also important. If you make changes to your content less frequently, it is easier to plan your publishing schedule in advance. If you make frequent changes, check that updating sources, regenerating content and uploading files fit in with your editing workflow.
The cPanel control panel can be useful if you wish to manage your hosting settings via a web interface. Publishing static files does not necessarily require server administration in itself, but the control panel can make your hosting settings easier to manage. You can tailor aWh’s web hosting solutions to the management requirements of your project.
aWh’s web hosting plans include daily backups, DDoS protection and an SSL certificate. Unlimited bandwidth and storage space are also standard features of the web hosting plans. In addition to these, consider whether you are likely to need a database, login functionality or other dynamic features in the future. This will help you avoid choosing a hosting plan based solely on your current files, which may no longer be suitable for your planned expansion.
Four questions can help you choose the right hosting: what features does the website use, how are the finished files transferred to the hosting server, how much control over management is required, and which hosting category is best suited to this setup. If the project displays pre-generated files, static hosting may be suitable. In the case of server-side processing or a database, it is worth considering other options as well.
General website hosting needs are met by web hosting, whilst cPanel Hosting is ideal for those who wish to manage their hosting settings via a web-based control panel. The cPanel hosting guide provides more detailed information on using cPanel hosting and the control panel. For static sites, you need to upload the generated files, not necessarily the entire development project.
A KVM VPS may be the right choice if your project requires greater server-side control or a scalable environment. The KVM hypervisor allows Linux and other operating systems to be virtualised. KVM VPS hosting therefore caters to different operational needs than static hosting, which is used to publish pre-prepared files. Base your decision on the requirements of your application and the server tasks you are able to manage.
aWh’s range of services includes web hosting, cPanel hosting, static hosting and AMD Epyc KVM VPS. Static website hosting is suitable for projects that use a file-based publishing process. If you later require a database or server-side logic, simply adjust your hosting plan to meet your new requirements.
Before you start, prepare the files generated by the generator that are intended for publication. Then assign the domain to the appropriate hosting plan, upload the files to the designated location, and check the site on the domain. Check that the home page, subpages, images and links are loading correctly. If you are using HTTPS, also check that the SSL certificate is set up correctly.
aWh’s services include Instant Activation and Free Migration. The web hosting plans include daily backups, DDoS protection and an SSL certificate. These are important factors to consider when assessing security and recovery, but you should always choose the specific hosting category based on the nature of your project.
Once you have selected the appropriate category, browse aWh’s web hosting options and tailor your choice to your project’s features, publishing method and management requirements. Prepare your files, set up your domain, then check the published site.
When choosing hosting for a static website, consider not only the current situation but also the next stage of the project’s development. If new content, additional subpages or interactive elements are added to the site, review whether the hosting and publishing process still meet your requirements. This way, the technical infrastructure can evolve alongside the website.
aWh has over 10 years’ experience in the web hosting industry. The provider guarantees 99.9 per cent uptime, and its support team is available 24 hours a day. Please bear these factors in mind when assessing operational continuity, alongside the project’s features.
Once you’ve assessed what kind of service you need, take a look at the available options and choose the solution that best suits your project’s requirements. Check out aWh’s hosting solutions and get started on publishing your website.
Static website hosting is used to store and serve files that have been prepared for publication. Check that the contents of your project’s output directory can be uploaded and that the home page is named correctly. A test publication will help you identify any routing errors. For example, subpages may load, but images may not appear because the directory structure is incorrect.
The most important difference lies in the way content is produced and edited. With a static website, updating content may require separate publication steps; in a dynamic system, an authorised editor can modify the data via the admin interface. Consider who will make the changes, how often new content is published, and whether editorial access without technical assistance is required.
An installed WordPress site cannot simply be run as a static file, as it requires a server-side environment. However, static output can be generated from WordPress-based content, which is then published as files. Before opting for this, check that the forms, search function, plugins and editing processes you use will work in the static version. If you need direct access to the WordPress admin panel, WordPress hosting may be a more suitable option.
The files being served do not require a database, but the system preparing the content may use one. For example, articles can be retrieved from a content management system before generation, and the published page can then be displayed without a database connection. When planning, distinguish whether the database is required to serve visitors or is merely part of the editing process. This will give a clearer picture of the environment required.
A showcase-style catalogue may be suitable if simply publishing product details is sufficient and visitors do not place orders directly on the site. For live sales, you need to manage the shopping basket, stock levels, order confirmation and the payment process. The associated services, data transfer and error handling must be designed separately for these functions. This ensures that the requirements of a product showcase site are not confused with those of a full-scale ordering system.
It is worth redesigning the site structure if the current publishing system no longer supports the work of content editors, or if the site is to incorporate new interactive features. Before making the change, list the existing site’s navigation paths, forms and external links, then determine which functions require a dynamic backend. It is not necessarily the case that every page needs to be redesigned; the scope of the changes will be determined by the specific requirements.
Yes, it can be secure if managed properly, but a static structure alone does not eliminate all risks. Do not leave passwords, access keys or other confidential data amongst public files, as visitors can download them. Protect administrative access with a strong, unique password, and keep the project’s components up to date. You should also check the data flow of the forms.
]]>Before making a decision, assess the expected load and how much time you can devote to monitoring the server. As a guideline, a small, basic Minecraft server might require 2–4 GB of RAM, whilst larger modpacks may require considerably more memory. The actual load is influenced by player activity, server settings and the areas of the world that have been loaded.
In this guide, we’ll compare a local machine, a game server service and a VPS, before going through the main technical considerations for choosing and setting them up. We’ll also cover the operating system, the Java version, the server software and access security. This will enable you to tailor the environment to your intended use and avoid having to guess when sizing your setup.
A server environment that is constantly available removes one of the fundamental limitations of a home computer: you don’t need to keep your own computer switched on to access the online world, and your home internet connection doesn’t determine the server’s availability either. This is particularly handy if your friends play at different times. When making your choice, however, consider how much customisation you need and how much time you’re willing to spend on running the system.
A local machine can be a good starting point for testing or casual gaming. The server runs on the same computer that you can use for other tasks. If the machine shuts down or restarts, or if your home internet connection is interrupted, players will be unable to access the game world. Performance may also be affected by other programs running on the computer.
Minecraft Realms is a convenient, game-related subscription service where you have fewer server management tasks to deal with. In return, you have less server-side freedom than on a VPS. If you require custom software, detailed configurations or your own resource planning, Realms may be more restrictive. This general overview of Minecraft servers will help you understand the differences between server environments and how they are managed.
A VPS provides a separate virtual environment that can be managed remotely. You can choose your operating system, install the necessary software and customise the settings to suit your own needs. KVM-based virtualisation provides an isolated virtual server environment. When making your choice, the AMD EPYC processor and NVMe SSD storage are important technical considerations, but these do not in themselves guarantee a specific level of gaming performance.
A Minecraft server VPS may be the right choice if you want a world that is regularly accessible to multiple players and if having control over the server settings is important to you. In a modded environment, it can be particularly useful to be able to tailor the software and configuration to your own needs. When planning, take into account the number of players, the mods, and the size and activity level of the world. These factors together determine the resource requirements, so there is no single package size that is suitable for every use case.
aWh’s AMD Epyc KVM VPS is built on NVMe SSD storage, redundant storage and built-in DDoS protection. Protection can be an important consideration for a publicly accessible server, but it is no substitute for secure access management and updates. When selecting the right KVM VPS environment, compare the resources with your expected workload and also consider how much server administration you are willing to undertake.
A VPS is not a ready-made Minecraft server, and does not involve the installation or managed operation of the game. It is your responsibility to install, update and configure the server software, secure access and back up your world data. If you are looking for a solution that requires minimal configuration, Realms may be a better option. If you want full control and flexible configuration, a VPS offers greater freedom.
The load on a Minecraft server is not determined by a single factor. It depends on the game version and release, the server software, the settings, and also on how actively players are exploring the world. When choosing a VPS for a Minecraft server, you should therefore first assess the expected usage, then monitor the server’s performance under actual load during a trial run.
There are no universal resource recommendations that apply to all Minecraft servers, as player activity, mods, the server version and the size of the world all combine to determine the load.
The Java Edition and Bedrock Edition require different server software, installation environments and compatibility requirements. For the Java Edition, the Java version of the runtime environment must match the selected Minecraft version, whilst the Bedrock Edition has its own dedicated server edition. The exact requirements may vary by version, so please check the current documentation for the server version before installation. This also applies to modified server software: please check that any plugins are compatible with your chosen edition.
The simultaneous activity of players directly affects resource usage. If everyone is building in one place, fewer new areas need to be loaded than when players are scattered across the map exploring it. Creating and loading new areas can increase the load on the processor and memory. The demands of mods and add-ons also vary: a simple command add-on does not necessarily place the same load on the system as a complex mod pack or numerous active in-game elements.
The main resources perform various tasks:
During the trial run, monitor memory and CPU usage, disk usage and logs. Test the system during quiet periods, and then again when several players are moving around or loading new areas at the same time. This will help you identify any bottlenecks, so you don’t have to size the server based purely on estimates. The technical specifications of KVM VPS environments help you compare the available resources, whilst your own trial run will reveal the actual requirements of the Minecraft server.
When choosing the right VPS, don’t just look at the amount of memory. The operating system, control over the server, future scalability and the method of administration all determine how well the environment suits your Minecraft plans. When choosing a VPS for a Minecraft server, it’s worth considering two decisions separately: first, the virtual server environment; and second, the Minecraft edition, server software and settings.
Linux VPS is based on command-line management, so it may be suitable if you are confident using a remote terminal and commands. The Windows VPS offers a graphical user interface for administering Windows Server, but updates and system settings must still be managed via the interface. When making your choice, consider which system you have experience with and how much manual management you are willing to undertake.
| Criteria | Linux VPS | Windows VPS |
|---|---|---|
| Operating system | Linux-based server environment | Windows Server |
| Management method | Typically command-line | Can be managed using the operating system’s tools |
| Control | Independent system and server configuration | Independent system and server configuration |
| Scalability | This depends on the resources allocated to the VPS and the capabilities of the service | This depends on the resources allocated to the VPS and the capabilities of the service |
| Administration | Requires knowledge of Linux | Requires knowledge of Windows Server |
When selecting a server environment, consider the planned game world, any modifications and the expected activity of players. Based on these factors, estimate your requirements for processing power, memory and storage space. A larger game world and more backups may require more disk space, whilst mods can increase the load on memory and the processor. The number of players alone is not a sufficient basis for sizing.
NVMe SSDs provide fast storage, making them a relevant technical consideration when storing world files and the data required for server operation. It is also worth taking the network environment into account, particularly if the server is to be accessed remotely. AMD EPYC processors and KVM-based virtualisation help in assessing the technical specifications of a VPS, but do not in themselves guarantee a specific gaming experience.
Selecting a VPS does not automatically install or configure Minecraft. The server software, the appropriate Java environment, the plugins and the in-game settings all require separate configuration. To allow for future expansion, you should also plan how you will monitor the load and how the allocated resources can be adjusted. You can compare the technical specifications of aWh’s KVM VPS range against these criteria.
Treat the installation as a three-step process: log in to the VPS, prepare the operating system, then install and check the Minecraft server. The necessary commands, execution environments and file names depend on the edition and server variant you have chosen. Follow the current documentation, not a command line intended for a different version.
You should choose Linux if you are confident using the command line and remote terminal connections. With a Windows VPS, you can work using the Windows Server administration tools. In both cases, treat accessing the VPS, configuring the operating system and installing Minecraft as separate tasks. The virtual server environment does not mean that the game server is pre-installed or pre-configured.
-Xms4G -Xmx4G startup settings set both the initial and maximum memory values to 4 GB. Do not apply this automatically to all VPS instances.After the initial start-up, check the log. Verify that the server has loaded the configuration without errors and created the necessary files. If you are prompted to accept the terms of use for the release, follow the instructions in the documentation. Then try to connect, check that the website loads correctly, and test your chosen modifications and plugins on a small scale.
Only allow necessary access through the firewall. Carry out server updates as planned, and back up the configuration and world files beforehand. Create regular, restorable backups, and check from time to time that data can be restored from them. The location of the backup matters too: do not store the sole copy of your data exclusively on the VPS on which the server is running.
Once you’ve assessed your resource requirements and operational tasks, take a look at aWh’s range of KVM VPS plans and choose the environment that best suits your planned Minecraft server.
When selecting the right Minecraft server VPS, ensure that the hardware specifications are tailored to the anticipated load. aWh’s KVM VPS, built on AMD EPYC processors, provides a fully customisable server environment. The infrastructure offers NVMe SSD storage, redundant storage and built-in DDoS protection. These are important factors to consider, but they do not, on their own, guarantee a specific gaming experience or uninterrupted operation.
KVM-based virtualisation provides a separate virtual server environment in which you can choose between Linux or Windows operating systems and install the programs required for your Minecraft server. AMD EPYC processors provide the computing power for the VPS. Don’t just consider the processor type: the game version, active mods, the size of the world and the actual activity of the players all combine to determine the required capacity.
NVMe SSD storage is a storage technology that ensures fast data access, whilst redundant storage forms part of the infrastructure. Regardless of this, you should create your own restorable backups of your Minecraft world files. Built-in DDoS protection is one element of defence against network attacks, but it does not guarantee complete immunity from attacks, nor does it replace secure access management or regular updates.
Choose the operating system that best suits your system administration experience. A Linux VPS requires command-line management, whilst a Windows VPS uses the Windows Server administration environment. In both cases, you are responsible for installing and configuring the Minecraft server, selecting the appropriate runtime environment, applying updates, securing access and performing backups of world files. The VPS does not operate as a pre-installed or managed Minecraft server.
Before you begin, decide which version of Minecraft and server software you wish to use, then check the documentation for the required environment. Next, configure access and the firewall, carry out a test run, review the logs and test the connection. Initial monitoring may reveal whether the memory, processor or storage capacity will need to be adjusted at a later stage.
aWh’s support team is available 24 hours a day. To view an overview of the technical specifications and available environments for VPS, please see the information on aWh’s VPS options.
Running a Minecraft server on a VPS will get off to a good start if your technical choices align with your objectives and you have thought through the operational tasks in advance. Before launching your shared world, decide which version of the game you wish to use, assess the expected load, and establish a routine for updates, access management and backups. You can then fine-tune your resource allocation based on the experience gained during the trial run.
aWh’s KVM VPS environment features AMD EPYC processors, NVMe SSD storage, redundant storage and DDoS protection. These provide the technical foundation for custom configuration, but the installation and ongoing management of Minecraft remain your responsibility. To find out more about the environment, take a look at aWh’s VPS solutions.
Plan your Minecraft server’s resources and browse aWh’s range of KVM VPS plans to choose the right environment.
There is no single player count that applies to all setups, as the load is determined by a combination of player behaviour and server configuration. Do not estimate the capacity of your Minecraft server VPS solely on the basis of the number of concurrent players. Test the server in situations where players are simultaneously exploring new areas, fighting or using mods. You can adjust the resources based on the observed load.
Yes, if it’s important to you to manage your server’s settings and software environment yourself. Realms offers a simpler, ready-made solution, whereas with a VPS, you’re responsible for the server software, updates and monitoring its operation. For example, if you’re running a community world that requires a custom plugin, a VPS can offer greater freedom in terms of configuration. If you’d prefer minimal administration, Realms may be the more convenient option.
Yes, but the separate server processes share the VPS’s resources. Each world can use memory, processor power and hosting, particularly when players are active at the same time. Start with a single environment, then gradually add further worlds. After each expansion, check the logs and resource usage so you can see whether the entire configuration is working properly.
Yes, the world can be migrated if you also transfer the world data associated with the server version and the necessary configuration files. Before the migration, check that the new environment is using the same version of Minecraft and a compatible server program. After copying the files, check that the world appears in the expected location, that the settings have been retained, and that the mods used by players are loading.
Choose a system that you can manage safely and confidently, and which meets the requirements of the server software. If you have used Linux before, you may be familiar with command-line administration; for a Windows VPS, you will need to use the Windows Server management method. Before making a decision, check the documentation for your chosen version of Minecraft, the required runtime environment, and how you will manage updates and access.
Common causes include a stopped server process, incorrect connection details or a firewall rule restricting network access. First, check the log to see if the server has started, then make sure your friends are using the correct address and Minecraft edition. If the server is running but is still unavailable, check your network and firewall settings. Only modify rules whose effects you understand.
]]>In this guide, you’ll find a step-by-step checklist. We’ll show you how to minimise the risk of unauthorised access and data loss by keeping WordPress up to date, choosing plugins carefully, using strong passwords, implementing two-factor authentication and carrying out regular backups. We’ll cover the role of HTTPS, as well as how an accessible, usable backup can help with recovery.
The checklist also clarifies where the role of website settings ends and when hosting- or server-side protection comes into play. This allows you to see which tasks you can manage within WordPress and how these can be complemented by the appropriate hosting environment, such as cPanel hosting or VPS hosting.
WordPress security involves protecting access to your website, the data stored on it and its operation. It is not just a matter of technical settings: updates, user accounts and the hosting environment all influence how secure your website is. The Wikipedia article on WordPress provides an overview of its structure and main components. To plan your security strategy, it is worth understanding how the core of the system, themes and plugins are interconnected.
The most common risks include out-of-date software, weak passwords or those used in multiple places, a lack of two-factor authentication, and a vulnerable plugin. These can each cause problems on their own, but together they create a larger attack surface. On a compromised website, content may be altered without authorisation, data may be lost, or the site may be temporarily taken offline.
Key takeaway: Securing WordPress does not depend on a single plugin, but on interdependent layers comprising up-to-date software, secure access and a suitable hosting environment.
The WordPress core, themes and plugins are separate components, so you should check their update status individually. Even with an up-to-date WordPress core, an out-of-date theme or plugin can still pose a risk. Remove any components you no longer use, as leaving them installed unnecessarily increases your attack surface.
Up-to-date software alone is not enough. Only grant administrator privileges to those accounts that need them, and assign a unique, strong password to each user. Two-factor authentication provides an additional layer of security, meaning that a compromised password alone is not necessarily enough to gain access.
The consequences of the incident depend on the type of website and the data affected. Pages, posts or settings may be altered, but it is also possible that the site or part of it may become temporarily unavailable. Without a usable backup, recovery may be more difficult, and some data may be lost permanently.
A system failure can also disrupt customer service. Unauthorised changes to content or an inaccessible website can also undermine visitors’ trust. This does not mean that every vulnerability will inevitably lead to an attack. Regular risk assessments, restricting account permissions and implementing hosting security measures can collectively minimise the likelihood and impact of an incident.
Effective WordPress security consists of several complementary measures. In WordPress, you can control user access, manage updates and select the necessary plugins. Hosting and server-side protection is a separate layer, relating to the operating environment and data backup. Neither area can replace the other.
The security plugin can be a useful addition: for example, it can help detect suspicious activity or manage certain security settings. It does not automatically fix an outdated template, strengthen a weak password, or replace server-side security or backups. The Wordfence guide on the basics of WordPress security provides further guidance on protecting logins and plugins.
Summary: Site-level measures protect your WordPress settings and accounts, whilst hosting-level protection complements the security of the environment hosting them.
Assign a separate account to each user and grant only the permissions necessary to carry out their specific tasks. Use a strong password that you do not use for any other service. Two-factor authentication requires an additional verification step after the password has been entered. This means that a compromised password alone is not necessarily sufficient to gain access. This is an important layer of account protection.
HTTPS encrypts the data connection between the browser and the website, thereby protecting traffic during transmission. SSL certificates help to establish an HTTPS connection. However, an encrypted connection does not update WordPress components, nor does it prevent unauthorised access. Regular backups serve a different purpose: they provide a means of recovery should data become corrupted or altered.
When choosing a hosting provider, it is also worth considering security, as your website’s settings and the operating environment both play a part in its protection. When selecting a web hosting service compatible with WordPress, take into account access protection, updates and data backups.
For sustainable security, don’t just check a single setting – follow a logical sequence. First, review who has access to the admin panel. Next, check for updates, and finally, ensure that backups are accessible and can be restored. This way, you can prepare not only for authorisation issues and known software bugs, but also for data loss.
In short: check access rights, update components, remove unnecessary items, verify that backups can be restored, and then test the changes.
In the admin panel, check the update notifications for the WordPress core, themes and installed plugins separately. Before updating, consider whether you actually need the item in question. If you no longer use something, remove it rather than simply deactivating it. Before carrying out a major update or changing settings, create a restoreable backup. For important business websites, test the new changes first and only then apply them to the live site.
Choose plugins from reliable sources, and avoid installing multiple tools that perform the same task. Each additional component requires separate maintenance. Keeping everything up to date is therefore an ongoing task: after an update, check that the website’s basic functions are still working properly.
The backup only provides a genuine means of recovery if it is accessible and usable when needed. Make sure you know where your backups are stored, the login details required to access them and the restoration process. From time to time, check the recovery steps as well, not just whether a backup has been made. When choosing a hosting provider, also consider the backup options offered by web hosting services that are compatible with WordPress.
Automatic backups can reduce the number of manual backup tasks, but they do not make knowledge of the restoration process redundant. As a website owner, you need to know how to access your backups and what to do if restoration is required following an update or a faulty change.
An unusual warning on its own does not prove that the website has been hacked, but it may warrant a check. In the event of unknown changes, unexpected redirects, new administrator accounts or notifications of failed login attempts, act quickly but carefully. Part of WordPress security involves recognising suspicious anomalies, preserving the information needed for investigation, and not deleting files without evidence.
Check whether any unknown content has appeared, whether the homepage has changed, or whether there are any redirects that you did not set up. Also review the administrator accounts and the most recent changes. A browser warning warrants further investigation, but does not in itself reveal the cause of the problem. If you have access to your hosting or WordPress logs, save them for analysis.
First, document what you have observed and keep any available logs. Do not hastily delete files, accounts or database entries, as important clues may be lost. If the investigation is beyond your technical expertise, consult a qualified specialist or support staff experienced in managing the hosting environment. A swift, methodical investigation can help prevent the recovery process from causing further data loss.
If your website is part of your business operations, both rapid recovery and a suitable hosting infrastructure are important. Discover aWh’s web hosting solutions and choose the one that best suits the operation of your WordPress website.
Securing a WordPress website is a shared responsibility. You are responsible, amongst other things, for user accounts, updating WordPress, themes and plugins, and the content of the website. The hosting provider provides security layers relating to the operating environment. Together, these two areas help to maintain WordPress security, but neither can replace the other.
aWh’s hosting solutions include backups, HTTPS, two-factor authentication and an AI security system. These serve different purposes: backups provide a means of recovery, HTTPS protects the data connection between the browser and the website, whilst two-factor authentication provides an additional layer of login verification. The AI security system complements the hosting environment by providing an additional layer of protection.
No single feature can eliminate all threats. Backups, for example, do not prevent unauthorised access, whilst HTTPS does not fix a vulnerable plugin. Find out which security tasks are part of your WordPress settings and which are linked to your hosting. In this way, the features do not replace one another, but complement each other to ensure the smooth running of your website and the protection of your data.
As your website’s traffic, content or number of features grow, its resource requirements and the way it is managed may also change. At such times, you should review whether your hosting plan is suited to your website’s current operations and what administrative options it provides. In addition to security, you should also take into account manageability and the specific needs of your website.
cPanel is the web hosting control panel that allows you to manage the settings for your hosting and individual website services via a graphical interface. Whilst this can make administration more straightforward, you will still need to manage WordPress updates and account security separately. To choose the right solution, take a look at aWh’s web hosting solutions and compare them with your website’s operational requirements.
If your website’s resource requirements or management methods change, it is worth considering whether a different hosting solution might be better suited to its operation. VPS hosting can provide websites with greater resources and scalability. aWh’s VPS solutions are one possible component of the technical infrastructure. cPanel support provides a web-based control panel for hosting tasks.
A VPS on its own does not keep the WordPress core up to date, does not check all plugins, and is no substitute for backups or account security. When making your choice, consider who manages your WordPress settings, how you access backups, and what hosting tools you can use. Clarify the roles of both application-level maintenance and infrastructure in ensuring your website’s security.
If you’re considering switching hosting providers, take a look at aWh’s web hosting range and choose a solution that suits the needs of your WordPress website.
As a next step, assess how visitors use your website and which features are essential for day-to-day operations. This will help you tailor technical decisions to the site’s actual requirements. To maintain WordPress security, regularly reassess whether your chosen operating environment meets the website’s needs.
If your website is expanding or its usage is changing, you should also consider resource and management aspects. You can choose from aWh’s web hosting, WordPress and cPanel hosting, and VPS solutions based on your current needs.
Discover aWh’s web hosting solutions and set up a well-thought-out operational infrastructure tailored to your website’s needs.
Not necessarily. The default settings are a good starting point, but they do not automatically suit every website’s users, content and functionality. For example, if your site does not use public registration, consider whether it is necessary to allow new users to be created. For WordPress security, after installation, review the accounts, administration settings and the features required for your website.
No. A plugin may support certain checks or security tasks, but it does not take over the full maintenance of the website. You’ll still need to keep an eye on accounts, updates and backups, as well as ensuring the site functions correctly after any changes. You should also review your security plugin’s settings from time to time, as poorly configured alerts can mask important warnings.
Plugin updates may contain bug fixes and security patches, so using an outdated version can pose a risk. Before updating, check whether you still need the plugin in question and make a note of which features you use. Then try out, for example, the forms, the search function or the payment process, if these are part of the site. This way, you’ll notice more quickly if the update has caused any operational issues.
No. HTTPS protects traffic between the visitor’s browser and the website, but it does not prevent, for example, someone from attempting to access the site via a vulnerable plugin. An encrypted connection also does not protect your account if someone logs in using a stolen password. HTTPS is an important foundation, but the security of your website also depends on your WordPress settings, access permissions and the operating environment.
Unfamiliar content may appear, unauthorised changes may occur, data may be lost, or the site may become temporarily unavailable. The exact impact depends on which accounts, files or data have been accessed. If you notice any suspicious changes, make a note of what you observed and when it happened. Do not delete any files immediately, as the logs and the affected files may help to investigate the incident. If the recovery process is beyond your expertise, seek professional assistance.
Yes, provided the backup is usable, accessible and contains the necessary website files and the database. Restoring the site may also overwrite content that was added to the site after the backup was created, such as new orders or posts. First, assess what recent data might be lost and preserve the current state. Understanding the backup process will help you prepare for recovery.
No. Hosting provides layers of protection related to the server-side environment, but it does not eliminate all risks. You are responsible for maintaining WordPress and its plugins, managing user accounts and ensuring strong passwords. Hosting and website-level measures can together mitigate the risk, but neither renders the other unnecessary – both require regular monitoring.
]]>It is not always clear whether a change should be made via the domain registrar’s interface or the hosting control panel. The two interfaces serve different purposes: name server settings are typically linked to the domain, whilst cPanel is used to configure the hosting and the DNS records managed there. Before making the change, make a note of the existing records, particularly if you wish to continue using your email service as normal.
In this guide, you’ll learn the difference between name servers and DNS records, as well as how to prepare for and carry out the migration in a safe and orderly manner. We’ll show you how to check the new settings, what to expect during the propagation period, and when it’s worth troubleshooting. We’ll also cover the technical checks required for .hu domains.
Name servers specify which DNS server is responsible for domain queries, i.e. where the DNS data associated with the domain can be found. The DNS server links the domain name to the data for the associated services. Based on this, the browser, for example, finds the website address, whilst the email system determines where to deliver messages. Changing the name server therefore involves specifying which DNS server should manage the domain’s zone.
Domain registration and web hosting are separate services, linked via DNS settings. Domain registration secures the domain name, whilst hosting provides space for website files and other services. The two services can also be managed via separate interfaces. cPanel is used to manage hosting; it is not the standard place for modifying name servers.
A name server points to the server responsible for the domain’s DNS zone. The records in the zone determine which data is associated with each service. The summary entitled ‘How Name Servers Work in the DNS’ also explains the role name servers play in name resolution.
When a record is updated, only the target in question changes, whilst the management of the DNS zone can remain in the same place. Replacing the name servers, on the other hand, transfers the entire zone management to a different DNS server. Simply specifying the new name servers does not, in itself, create the A, AAAA or MX records. These must also be included in the new zone; otherwise, the website or email service may not function correctly.
When switching hosting providers, you may need to change your name servers if you wish to manage the domain’s entire DNS zone within the new environment. It may also be necessary if you transfer your DNS management to another service provider. If you are only changing your website address or email settings, it may be sufficient to update the relevant records whilst leaving the name servers unchanged.
Transferring a domain does not, in itself, change the name servers. Registration affects the service provider managing the domain, whilst the name server settings determine where the DNS zone is managed. Before switching, obtain the name server details for the new environment and assess which records you need for your website and email.
During the planning stage, clarify the following in advance:
During the preparation process, don’t just make a note of the current name servers. Save the important details of the DNS zone so that you can compare the old and new settings. You can take a screenshot or make a copy of the records, but check that the values, record types and names are clearly legible.
Before making any changes, make a note of at least the A, AAAA and MX records, as well as the SPF and DKIM details relating to email authentication. Also make a note of which setting belongs to which service. This will make it easier to spot if a record is missing from the new DNS environment or has been accidentally altered.
The availability of a website is determined by the correct value of the A or AAAA record. Please check that the address used for the website is listed in the new zone. The routing of emails is determined by the MX records. If these are missing or differ from what is required, email delivery may also be affected. Please also retain the SPF and DKIM settings, as these are related to email authentication.
If the website and email are managed by separate systems, the fact that one is working does not prove that the DNS settings for the other are also correct. It is particularly important to retain the records required for email if the website is being moved but the email service remains unchanged. In such cases, you should also include the email hosting settings in your pre-migration assessment.
Important: the records required for the website, email and other relevant services must also be included in the DNS zone of the new name servers. Changing the name servers does not transfer this data.
Before configuring the new name servers, review the managed zone and check that all necessary records are present. Also take note of the DNSSEC status: the security data stored in the domain registry and on the DNS server must be consistent. The steps involved in the transition depend on your existing settings, so do not apply the same DNSSEC changes to every domain.
Changes may not be immediately visible on all networks. The explanation of DNS propagation summarises why different DNS records may appear during the transition. Preparing in advance helps to distinguish between a temporary update and a missing or incorrect record.
The choice depends on whether you wish to transfer management of the entire domain’s DNS zone elsewhere, or simply change the purpose of a single service. As these two operations affect different areas, you should first clarify exactly which setting you wish to change.
| Action | When is it advisable? | What’s changing? |
|---|---|---|
| Name server change | It would move the entire DNS management to a different environment. | The new name server manages the domain’s DNS zone. |
| Editing a custom record | It would update the purpose of a service. | Only the value of the selected record – such as A, AAAA or MX – changes. |
Understanding the basics and workings of DNS helps you grasp how records are linked to the services assigned to a domain. The right solution depends on where you wish to host and manage the entire DNS zone.
Please also select the relevant functions within the control panels separately. cPanel is the interface for managing your hosting account, where you can manage settings relating to your hosting. The exact location of the nameserver settings within the domain registrar’s interface may vary from provider to provider. cPanel is therefore not the standard location for changing nameservers.
Changing your name servers is appropriate if you want the entire DNS zone for your domain to be managed by a new provider. This is a common option when switching hosting providers, but it is not required for every migration. If you keep your DNS management with your current provider, you may only need to update certain records. Before making a decision, review the contents of the new zone and check that it meets the requirements of your website, email and other services you use.
Compare the new zone with your current settings. If your DNS management remains in one place but the purpose of your hosting changes, updating only the relevant records may be a more targeted solution. This way, you won’t have to transfer the management of the entire zone just because you need to change the address of a single service.
If you are simply changing the purpose of your website, it may be sufficient to amend the A or AAAA record. If the email routing changes, please review the MX record. In this case, the name servers can remain unchanged if you can edit the relevant record at your current DNS management site. The aWh DNS records management knowledge base offers relevant guides to help you review the settings.
A website or email outage is not an inevitable consequence of the migration. You can minimise the risk by identifying the necessary changes in advance and ensuring that the records required for operation are also available in the new environment. Before making a decision, consider the following: are you changing the purpose of a single service, or do you wish to transfer the management of the entire DNS zone?
Name server changes are usually made via the domain management interface. The exact menu options and labels may vary depending on the registrar, so the steps below are intended as a general guide. Before making any changes, please ensure you have the name server details for the target system and the DNS records required for the changeover.
For .hu domains, one of the requirements for registry verification is that there must be at least two name servers with independent IP addresses that provide authoritative responses for the domain. If the change cannot be saved or the verification fails, first check the settings of the new DNS environment; do not repeat the attempt without making any changes.
Check whether the control panel has confirmed the backup and whether the new name servers appear in the domain settings. The change recorded in the control panel and the fact that the result is visible in all queries do not necessarily happen simultaneously. Therefore, the first query showing a discrepancy does not in itself prove that there is an error.
If your website or email is not working, check that the records you previously noted down are present in the new DNS zone. Check the settings for your website and email separately. You can also review the interfaces and options for managing your domain on the domain registration management page. If you are planning to register a new domain, take a look at aWh’s domain registration options.
After saving, the updated DNS data may not be immediately visible at all query points. This process is known as DNS propagation: different DNS servers may receive the new data at different times, whilst some locations may still display the previous information. The duration of the transition may depend on previous DNS settings, the TTL values of the records, and the caches of the systems making the queries.
The update can often take anywhere from a few minutes to a few hours, but you may have to wait longer. There is no exact timeframe that applies to all domains and networks. Do not change the settings again simply because a single check still shows the previous data. Compare the results at several different times, then examine each service individually.
Check that queries for the domain are now being answered by the new name servers. Then test the services associated with the domain separately. Check in your browser that the website is pointing to the correct destination, and when using email, send and receive test messages. Do not automatically draw conclusions about the status of one service based on the results of a test on another.
If you notice any discrepancies between the queries, make a note of which data you received and when. Comparing the results will help you distinguish between an ongoing update and an error in the DNS zone. Bear in mind that the results may also be affected by the caching of the checking tool or your own network.
If the website is unavailable, first check whether the required A or AAAA record is present in the new zone and whether its value matches the details of the target system. In the event of an email error, check the MX records and then compare them with the previously recorded SPF and DKIM details. Do not delete or overwrite other records at random, as this may affect the operation of other services.
When using DNSSEC, please also check that the DNSSEC records associated with the domain are compatible with the new DNS environment. The steps required depend on your existing settings, so do not automatically apply the same changes to every domain. If your website or email still does not work after checking the records, the values you noted down before saving will help you identify which record or setting has changed.
When choosing a new domain or hosting, take a look at aWh’s domain solutions and web hosting options. Domains and hosting are separate services, linked together by the appropriate DNS settings.
Changing your name servers is a good opportunity to review how you manage your online presence. Take stock of the services you use, your access rights and the security settings you check regularly. This will make it easier to plan any future changes and ensure your administration remains transparent.
If you’re looking for a new domain or would like to review your current domain management options, choose the solution that best suits your needs. Among aWh’s domain registration and web hosting options, you’ll find a range of starting points, from cPanel and WordPress hosting to VPS hosting.
Take a look at aWh’s domain registration and web hosting options, and plan the next step for your online presence.
Please change the name servers via the domain management interface at the registrar where your domain settings are accessible. After logging in, check the domain name before making any changes. For secure access, use a strong, unique password and, if available, enable two-factor authentication. cPanel is used to configure your hosting account; it is not the general platform for domain registrar operations.
There is no fixed deadline that applies to all domains and networks. If the new details have not yet appeared, make a note of the time of the change, then check again later using the same domain name. This will allow you to compare the results. If the registrar’s interface displays an error, or if the setting did not save, do not start troubleshooting by waiting; instead, check whether it was saved.
Changing the name servers does not in itself delete the website’s content, but the website’s availability depends on the settings of the new environment. When checking, try opening both the main domain name and the ‘www’ version, if you use both. Check whether the expected page appears or whether a browser error is displayed. Check separately that the website’s files are present on the hosting server.
Yes, this may affect the email associated with the domain, so please check that you can send and receive emails after the changeover. It is important to note that changing the DNS settings will not transfer the contents of your email accounts or any previous messages. If your email runs on a separate system, the accounts and login details will remain linked to that system. During the test, please also send a message from an external address.
Changing the name servers alters where the domain’s DNS is managed, whilst editing a single record only affects a specific setting. First, clarify whether you wish to manage the entire DNS zone in a different environment or simply change the settings for a single service. Before modifying a record, check that the data associated with the other, unchanged services remains accessible.
No, changing the name servers does not require you to perform a transfer of the domain. The domain can remain with its current registrar whilst DNS management is transferred to another system. Before making any changes, ensure that you have access to the domain’s control panel and have the exact details of the new name servers. This will help you avoid any delays in the transition caused by a lack of access or the necessary information.
The cause may be missing or incorrect DNS settings, or it could be a fault with the service itself. First, make a note of the exact error message and whether the website, email or both are affected. Next, compare the results of the service when it is working with those when it is faulty, then check the details of the new zone. If the domain uses DNSSEC, take its settings into account as well. Do not make several random changes at once.
]]>