Volixta SSL & Security Headers

No. Volixta can detect an existing public certificate or request a free Let’s Encrypt certificate for an eligible public domain. If your hosting provider already manages SSL, you can continue using that certificate.

Yes. Volixta includes an ACME v2 client and supports Let’s Encrypt certificate requests using the HTTP-01 challenge. The domain must be publicly reachable and meet the certificate authority requirements.

Yes, when a supported hosting integration is configured. Volixta supports certificate installation through cPanel, Plesk, and DirectAdmin integrations. If automatic installation is unavailable, the generated certificate files remain available for manual installation.

Yes. Eligible Volixta-managed production certificates can be checked through WP-Cron. When a certificate reaches the renewal window, Volixta can request and install a replacement when the required hosting integration is configured.

Once a valid certificate is available, open Volixta and follow the Guided Setup or the SSL & HTTPS section. Volixta can update the WordPress Home URL and Site URL to use HTTPS.

Volixta can enable a permanent 301 HTTPS redirect. On Apache and LiteSpeed, the redirect can be added inside a Volixta-managed .htaccess block. For Nginx, Volixta provides the configuration that needs to be added to the server.

No. Volixta is designed to manage only its own marked sections inside .htaccess. For example:

• # BEGIN Volixta HTTPS Redirect
• # END Volixta HTTPS Redirect

The Safety Backup is a recovery copy of the current .htaccess file. You can download it before changing redirects or server Security Headers. If a server configuration problem makes WordPress unavailable, the backup can be restored manually through your hosting File Manager.

Yes. Supported sensitive .htaccess operations create an automatic rollback backup before the file is changed. You can also create and download a manual Safety Backup.

Volixta does not intentionally delete or replace the whole .htaccess file. The uninstall process only attempts to remove Volixta-managed blocks. Before modifying an existing .htaccess file during uninstall, a verified recovery snapshot is required. If that snapshot cannot be created safely, the existing .htaccess file is left unchanged.

Mixed content happens when an HTTPS page still loads one or more resources through HTTP. This can include images, scripts, stylesheets, fonts, or embedded resources.

No. Frontend checks and scans do not permanently modify WordPress content. Permanent changes are made only when you explicitly use Database Cleanup.

Volixta handles eligible serialized WordPress values instead of performing a blind database-wide text replacement. As with any permanent database operation, keeping a normal website backup before cleanup is recommended.

The Live Fixer upgrades eligible insecure resource URLs while the page is rendered. It does not permanently change the stored database values. If your rendered frontend does not contain mixed content, there is normally no need to enable it.

Volixta supports common browser protections including HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP, and additional advanced policies.

Strict browser policies can affect external scripts, embedded content, APIs, media, fonts, or other resources. Volixta therefore provides a Recommended configuration and keeps more technical controls in the Advanced section. Review custom policies carefully before applying them to a production website.

Secure Cookie Protection strengthens WordPress authentication and PHP session cookies when HTTPS is enabled. Volixta can enforce Secure protection for WordPress authentication cookies and configure PHP session cookies with Secure, HttpOnly, and SameSite=Lax settings. Before persistent changes are made to wp-config.php, Volixta lets you download the current file directly to your computer. The backup is not stored on the server.

CSP Report-Only lets you test a Content Security Policy without blocking website resources. Browsers report policy violations to a local Volixta endpoint so you can identify scripts, images, connections, or other resources that would be affected before enforcing the policy. Volixta keeps only a limited local report history and does not store visitor IP addresses, user agents, referrers, or script samples.

For .htaccess changes, Volixta can create a recovery copy of the current file before managed server rules are changed. For wp-config.php changes, Volixta does not store a backup on the server. Instead, you can download the current wp-config.php directly to your computer before applying persistent Secure Cookie settings.

Yes. Nginx does not use .htaccess, so Volixta provides ready-to-copy configuration for supported HTTPS redirects and Security Headers instead of attempting to modify .htaccess.

Yes. Volixta detects common local environments such as localhost, .local, and .test. A public Let’s Encrypt certificate is not required locally. If you want trusted local HTTPS, Volixta provides guidance for tools such as mkcert.

Most plugin operations run only in the WordPress admin area. Certificate issuance, hosting communication, Deep Scan, Database Cleanup, and configuration operations do not run during normal frontend requests. Only explicitly enabled frontend features, such as the PHP redirect fallback or Live Fixer, add frontend processing.

Volixta does not include visitor analytics or usage tracking. Some features communicate with external services only when required for an operation you request, such as Let’s Encrypt certificate issuance or a configured hosting-panel connection.