A WordPress website should nowadays fundamentally have HTTPS be accessible. HTTPS encrypts the connection between your visitors' browser and the web server, thereby protecting, for example, login data, form inputs, and other transmitted information from being easily intercepted during transmission.
For HTTPS to work, your website requires a valid SSL/TLS certificate. With CURIAWEB web hosting, the technical foundation for this is already provided. Nevertheless, especially with existing WordPress installations, it may be necessary to update WordPress itself from http:// on https:// to convert.
Important: Having an existing SSL certificate does not automatically mean that your entire WordPress website is already being correctly served via HTTPS. WordPress, internal URLs, and redirects must also be configured correctly.
What is the difference between SSL, TLS, and HTTPS? #
The terms SSL, TLS, and HTTPS are often used interchangeably, but technically they do not mean the exact same thing.
- SSL The original technology for encrypting connections. The term „SSL certificate“ is still commonly used today.
- TLS The modern successor to SSL and the encryption technology actually used today.
- HTTPS: The encrypted version of HTTP. The „S“ stands for „Secure“.
When people in everyday life talk about an SSL certificate, they usually mean a certificate that enables an encrypted HTTPS connection.
Why should WordPress use HTTPS? #
HTTPS is not only relevant for online shops or websites with sensitive customer data. A standard corporate website or blog should also be transmitted with encryption.
This applies in particular to:
- WordPress logins via
/wp-admin/ - Contact forms
- Customer and user accounts
- WooCommerce stores
- Comments and other form inputs
- personal data transmitted via the website
Modern browsers also label websites without HTTPS as not secure or warn users about an unencrypted connection. HTTPS is therefore part of the basic technical configuration of a professional website today.
SSL at CURIAWEB #
With CURIAWEB hosting packages, SSL certificates are available for the hosted domains. Certificate management takes place at the hosting server level or via cPanel.
Before making any changes to WordPress, you should therefore first check whether a valid certificate already exists for the domain in question.
A simple initial check is to access your website via:
Replace your-domain.ch through your actual domain.
If the website loads without a certificate warning, a valid certificate is generally present for the domain being accessed.
Note: Do not switch WordPress to HTTPS as long as there is no working SSL certificate for the domain. Otherwise, your website may no longer be accessible correctly after the change.
Before switching to HTTPS: Create a backup #
With a new WordPress installation, HTTPS is often already correctly set up. With an older website, however, numerous URLs with http:// be stored in the database.
Therefore, you should always create a recent backup before making major changes to an existing website. This applies especially when URLs within the WordPress database need to be replaced later.
A backup should at least contain:
- the WordPress files
- the WordPress database
- the file
wp-config.php - additional configuration files, if necessary
Recommendation: Never make changes to URLs or the WordPress database without a current backup. An incorrect search and replace can damage a WordPress installation.
Switch WordPress to HTTPS #
If the SSL certificate is working, you can check which URLs WordPress is currently using.
To do this, log in to your WordPress admin area and open:
Settings → General
There you will normally find the two fields:
- WordPress Address (URL)
- Website address (URL)
In a normal WordPress installation, these might look like this, for example:
http://deine-domain.ch
For HTTPS they must be as follows:
So change it http:// in https:// and save the settings.
Warning: Only change these URLs if you are sure that the SSL certificate for the domain is working. Incorrect information for „WordPress Address“ or „Site Address“ can cause the website or WordPress admin area to become inaccessible.
Why are there two different WordPress URLs? #
On many websites WordPress Address and Website address identical. But that does not necessarily have to be the case.
The WordPress Address denotes the location where the WordPress installation is technically located. The Website address refers, on the other hand, to the URL visitors use to access the website.
For special installations, these values can be different, for example if WordPress was installed in a subdirectory.
Therefore, do not simply change both values in an existing custom configuration without first checking how WordPress was installed.
Automatically redirect HTTP to HTTPS #
After the switch, the unencrypted HTTP version of your website should not remain accessible parallel to the HTTPS version.
A call from:
http://deine-domain.ch
should automatically switch to:
be forwarded.
This redirection ensures that visitors and search engines consistently use the encrypted version.
Depending on the server configuration, HTTPS redirection may already be set up automatically or can be enabled via the hosting configuration. An additional manual modification of the file .htaccess is therefore not necessary in every case.
Important: Do not just copy any HTTPS redirect from the internet into your
.htaccess. Incorrect or duplicate redirect rules can cause redirect loops and make your website inaccessible.
What is mixed content? #
After switching to HTTPS, the website can in principle be accessible via HTTPS and still continue to load insecure content. This problem is called Mixed Content referred to as.
A classic example:
The actual page is loaded via:
However, one image within this page is still being loaded via:
http://deine-domain.ch/wp-content/uploads/beispiel.jpg
This means the HTTPS page still contains an unencrypted HTTP resource.
Mixed Content can occur, for example, in:
- pictures
- Stylesheets (CSS)
- JavaScript files
- Web fonts
- Videos or embedded media
- Theme settings
- Page Builder
- Plugins
- hard-coded URLs
Why do old HTTP URLs persist after the migration? #
WordPress stores numerous information in its database. If a website was originally built using HTTP, complete URLs may still be stored there with http:// be saved.
This affects, for example, images, links, widgets, theme settings, or page builder content.
The change of the WordPress address under Settings → General does not necessarily replace such already saved URLs automatically.
Therefore, it may be necessary to specifically target old URLs in the database from:
http://deine-domain.ch
on:
to replace.
Do not replace HTTP URLs directly with phpMyAdmin #
A common mistake is to run a simple SQL query via phpMyAdmin and directly replace all occurrences of a URL.
You should avoid this in WordPress if you don't know exactly which data is affected.
WordPress, themes and plugins can contain so-called serialized data save it in the database. Among other things, this involves taking into account the length and structure of data values. Improper replacement can damage these data structures.
For extensive URL changes, you should therefore use a WordPress-compatible search-and-replace method that can handle serialized data.
Warning: Do not perform a global search and replace directly in the WordPress database if you are not sure how serialized data is handled. Always create a complete backup beforehand.
Detect mixed content in the browser #
If the browser reports problems despite HTTPS, you can use the browser's developer tools.
In many browsers you open these via the developer tools and then switch to the Console. Mixed content issues are often displayed directly there.
Typical messages indicate that a page loaded via HTTPS is trying to retrieve a resource via HTTP.
The displayed URL helps you figure out which image, script, stylesheet, or other element still needs to be adjusted.
Clear cache after HTTPS transition #
After changing URLs or redirects, you should clear existing caches. Otherwise, you might continue to see an older version of your website and thus believe the transition did not work.
Depending on the WordPress configuration, there may be multiple cache levels:
- browser cache
- WordPress cache plugin
- Server cache
- Page Builder Cache
- CDN or proxy cache
Therefore, after the changeover, clear the relevant caches and then test the website again.
HTTPS with a CDN or Cloudflare #
If you are using an external CDN, proxy, or DNS service like Cloudflare, the HTTPS configuration may require additional settings.
In this case, an encrypted connection may exist between both the visitor and the CDN, as well as between the CDN and your CURIAWEB server.
Therefore, the SSL settings of the external service must match the web server configuration. An incorrect setting can lead to redirection loops or certificate issues, for example.
Note: If your website is run via an external proxy or CDN and a redirection loop occurs after switching to HTTPS, check its SSL or HTTPS configuration first.
HTTPS and WordPress SEO #
Switching from HTTP to HTTPS changes your website's URL. From:
http://deine-domain.ch/beispielseite/
becomes
To ensure that search engines clearly recognize the HTTPS version as the preferred variant, the technical configuration should be consistent.
Check in particular after the switch:
- HTTP is permanently redirected to HTTPS
- Internal links use HTTPS
- Canonical URLs use HTTPS
- the XML sitemap contains HTTPS URLs
- Images and other internal resources are loaded via HTTPS
If you manage your website in Google Search Console or other webmaster tools, you should also check after a major change whether the new HTTPS configuration is recognized correctly.
What to do if WordPress is no longer accessible after the migration? #
If you changed the WordPress URL and afterwards neither the website nor the admin area can be accessed correctly, it is often due to an incorrect URL or a faulty redirection.
Typical symptoms are:
- Too many redirects
- Redirect loops
- a white or unreachable page
- Redirection to an incorrect domain
- Certificate warnings
- The WordPress login is no longer working
In this case, check first whether your domain is actually reachable via HTTPS and whether the certificate is valid.
If you no longer have access to the WordPress admin area, the WordPress URLs can also be changed via the file if necessary wp-config.php can be specified. However, this is a technical troubleshooting step and should only be performed if you are familiar with editing WordPress configuration files.
If you are unsure, do not change database values or server configurations at random, but contact CURIAWEB Support.
How to check the HTTPS migration #
After completing the work, you should not only check the home page. Test several different areas of your website.
- Open your website via
https://deine-domain.ch. - Call additionally
http://deine-domain.chOpen it and check whether it automatically redirects to HTTPS. - Open several subpages and blog posts.
- Check images, menus, and internal links.
- Testing contact forms.
- Open the WordPress admin area.
- Check the browser console for mixed content messages.
- Clear existing caches and repeat the test.
For a WooCommerce store, you should also test the cart, checkout, and customer account.
SSL certificate and HTTPS are two parts of the same transition #
For a fully encrypted WordPress website, two things must work together:
1. The web server requires a valid SSL/TLS certificate.
Without a valid certificate, the browser cannot establish a trusted HTTPS connection to the domain.
2. WordPress must consistently use HTTPS.
This includes the WordPress URLs, internal resources, redirects, and, if applicable, URLs already saved in the database.
Only when both areas are correctly configured is the website completely switched to HTTPS.
Recommendation: Always fully check a WordPress website after an HTTPS migration. A padlock icon on the homepage alone does not prove that all subpages, resources, and redirects are configured correctly.
Problems with SSL or HTTPS on CURIAWEB? #
If your domain does not receive a valid SSL certificate despite active hosting, HTTPS does not work, or you can no longer access your WordPress website after a change, you do not need to make changes to server or WordPress files on a whim.
In this case, contact CURIAWEB support and provide the affected domain and, as precisely as possible, the error message displayed. This helps to determine more quickly whether the problem lies with the certificate, WordPress, a redirect, or another configuration.
Summary #
For a secure WordPress website, you need a valid SSL/TLS certificate and a WordPress installation correctly configured for HTTPS. First, check if your domain has https:// accessible without a certificate warning. Afterwards, you can check the WordPress and site address and change them from HTTP to HTTPS if necessary.
Ensure that HTTP calls are permanently redirected to HTTPS and that no old HTTP resources are loaded as mixed content. For older websites, additionally saved URLs in the WordPress database may need to be updated. Always create a backup before making such changes and use a method for database changes that can handle WordPress and serialized data.
When the certificate, WordPress URLs, redirects, and internal resources are correctly configured, your WordPress website will be delivered completely and consistently via HTTPS.
