Maintain your website with confidence.

Product overview

One administration area for privacy, recovery, protection, speed and search readiness.

Lodone brings essential WordPress maintenance tasks into a licensed plugin. It helps an administrator inspect the current state, make selected changes, preserve recovery copies and review the result. It is suitable for site owners who want these controls together and are prepared to review site-specific findings.

Read results in context

A score or a completed operation is a report about the checks performed. It is not a security certification, legal assessment, guaranteed speed improvement or promise of search rankings. The detailed findings, errors and public website tests matter more than a single number.

Requirements and navigation

Confirm the environment before enabling changes.

Where the controls are

There is no separate Maintenance and images menu in the plugin. Recovery belongs to Backups, file integrity and database maintenance belong to Security, and image optimization belongs to Performance.

Three simple automation controls

Enable routine work from Lodone > Automation. Technical options stay under Advanced.

1. 1
   Automatically optimize new images

   Enable this to queue future Media Library uploads and their generated thumbnails in the background. This is ongoing consent to send those images through the configured image service. Existing images are not processed retroactively.

2. 2
   Automatically check security

   Enable daily malware-pattern and file-integrity scans. A separate vulnerability-feed key is needed only for known-vulnerability data; missing that key does not stop local scans.

3. 3
   Strengthen login protection

   Enable progressive failed-login limits, tracking by IP, username and their combination, generic login errors, and a hidden bot trap on the standard WordPress login form.

4. 4
   Save your choices

   Select Save automation. Choices are per website. Existing independent security settings are retained; turning off the login enhancement removes its bot trap without disabling independently configured login limits.

Automatic optimization of future uploads

A saved choice replaces repeated confirmation for new images.

In Automation, enable Automatically optimize new images, expand Advanced if you want WebP or AVIF instead of the original format, choose lossless or smart compression, and save. Smart compression can alter pixels; review its suitability for your content.

After WordPress generates an uploaded image and thumbnails, Lodone queues it for background processing. The browser upload is not held open for image optimization. Existing media can still be processed manually from Speed > Images. Rebuilding attachment metadata does not automatically queue the same upload twice.

The existing image worker processes each size, preserves originals, validates output dimensions and format, and records progress and savings. Review the latest job and persistent Total results under Speed > Images. A queued status is not a completed optimization. Restore originals from the same image screen if needed.

Active overlapping image optimizers pause automatic processing. Busy jobs or temporary start errors are retried up to twelve times at five-minute intervals. The Automation screen shows the latest queuing reason; processing errors appear in the image-job details. Correct the problem and run a manual optimization for any remaining images.

Daily checks and login protection rules

Background checks report findings; they do not remove files.

Automatically check security starts a daily malware-pattern scan and file-integrity check. An already running scan is not restarted. Official WordPress checksum comparison needs access to the WordPress checksum service. Local change comparisons need a previously reviewed and explicitly saved baseline; automation does not silently trust a new baseline.

Known-vulnerability checks use the separately configured feed key. Without it, vulnerability coverage is unavailable while local scans remain scheduled. With it, feed errors are reported independently. Review scan completion, unreadable files, checksum errors and findings in Security; starting a check does not mean it completed.

Scheduled work uses WP-Cron and may run late without visits or a working host scheduler. The backup central wake-up service is not a universal guarantee for every security or image job. Configure optional report recipients and alerts in the advanced monitoring and integrity settings.

Strengthened login protection uses the existing configurable attempt threshold, time window and progressive lockouts. Defaults permit five failed attempts within fifteen minutes, with a fifteen-minute initial block and a configured maximum. Existing custom limits are retained. The hidden form field rejects submissions that fill a field intended to remain empty.

Review a finding and keep the file

Choose Reviewed - keep file when you have inspected a finding and trust the current contents.

1. 1
   Inspect the exact file

   Review its location, code, source and purpose. A PHP file inside uploads is a risk indicator, not conclusive evidence of infection. If unsure, seek help before trusting it.

2. 2
   Keep a reviewed file

   Select Reviewed - keep file on the finding. Administrator access, an active licence and a valid request nonce are required. The server checks the file against the scan SHA-256 before accepting the review.

3. 3
   Review remains visible

   The file stays in its original location and is labelled as reviewed. The decision records its exact content hash, reviewer and time. Findings remain visible rather than being silently deleted.

4. 4
   Changed file or undo

   A changed content hash invalidates the review; a new scan can flag it again. Use Undo review to remove a decision at any time. A file changed since the displayed scan cannot be approved from stale results.

Reviewed, unchanged findings are excluded from the unreviewed malware-alert count. Review is a local administrative judgement, not a malware-free certificate, and does not disable file-integrity checks or the request firewall.

Install, assign and activate

A downloaded ZIP alone does not enable the licensed tools.

1. 1
   Download the package

   Sign in at lodone.com/dashboard/ and download the current WordPress plugin ZIP from your licence area.

2. 2
   Assign the website

   Use the website/domain assignment control in the customer account, enter the intended host and save it. Keep one licence for each website. If the licence is still unassigned, successful plugin activation can assign the current host automatically.

3. 3
   Install in WordPress

   Open Plugins > Add New Plugin > Upload Plugin. Choose the ZIP, select Install Now, then Activate Plugin.

4. 4
   Activate the licence

   Open Lodone, paste the licence code and select Activate licence. Confirm that the state becomes Active and that the feature sections open.

5. 5
   Check the domain

   Compare the assigned website in your customer account with the WordPress site you activated. Resolve any mismatch before configuring the tools.

Licence lifecycle

Without an active licence, protected features and actions are unavailable. Automatic status refresh is due after approximately six hours and depends on WordPress execution. A known licence expiry is checked locally. An explicit invalid response disables the licence; a temporary transport failure can retain a previously valid state for up to 72 hours from the last successful validation.

Stopping renewal leaves access for the paid period. When that period ends or the licence becomes invalid, protected functionality is disabled. Recheck the visible status after account changes rather than relying on an old activation message.

Changing a website or updating

Use Change domain in the customer account, save the target website and select Check licence again in WordPress. Before an update, download a full backup. Use the offered update or replace the existing plugin with the current ZIP. Do not delete it as an update method. Verify the version, licence and saved settings afterwards.

First setup and Overview

Establish recovery and email before changing security or delivery settings.

Use Overview as a work queue

Overall status combines the latest available module results. Good, Warnings and Critical counts help prioritise review. Open the affected module for the finding, the time of the last check and the proposed action. Older results do not automatically describe the current state after a theme, plugin or hosting change.

Needs attention identifies next actions. Last activity helps distinguish a successful operation from a failed or incomplete one. Filters change the view of stored findings; they do not rerun a check.

What a full backup contains

A recoverable WordPress package with a defined scope, rather than a complete server image.

Exclusions and boundaries

WordPress core, the complete wp-config.php, operating system, hosting control-panel configuration, DNS, certificates, external mailboxes and arbitrary files outside wp-content are not copied. The .user.ini file is deliberately excluded. Reinstall a clean WordPress core and prepare target-host credentials during disaster recovery.

Known backup/download directories, generated caches, selected server-specific drop-ins, upgrade temporary folders and generated builder CSS are excluded to avoid recursive backups and unsafe migration of hosting-specific components. Symbolic links are not a dependable way to include external content. Review custom upload paths and unusual site layouts separately.

Create, schedule and preserve copies

A local backup is useful only while the host and its storage remain accessible.

1. 1
   Create

   Open Backups and select Create full backup. Allow database, file, archive and verification phases to complete.

2. 2
   Inspect

   Check Completed, creation time and SHA-256. Creation verifies the ZIP, manifest and database package; deeper SQL validation remains mandatory before restore. A failed operation is not a recovery point.

3. 3
   Download

   Download the completed copy. Confirm that the local file exists, has a plausible size and can be opened as an archive.

4. 4
   Keep it outside the host

   Store at least one recent copy on a device or storage location that will survive loss of the WordPress server. Keep the checksum with your recovery record.

Capacity and retention

Allow space for archives, temporary work and a full safety copy before restoration or database cleanup. Preserved image originals increase storage needs. Delete and Delete selected permanently remove the chosen archives after confirmation; keep an independent copy first. Retention does not prove that recent backups completed.

Backup encryption and recovery key

Choose encryption deliberately; it is disabled by default for new installations.

1. 1
   Choose the setting

   Open Backups > Encryption. Select Encrypt backup archives only if you want new backups protected with AES-256, then save the setting.

2. 2
   Download the recovery key

   When encryption is enabled, download the recovery-key file and store it separately from the website and backup destination. Do not keep the only copy beside the archives.

3. 3
   Create and verify

   New manual and scheduled backups follow the saved encryption setting, including copies uploaded to Dropbox or Nextcloud. Existing archives are not changed retroactively.

4. 4
   Restore after server loss

   On the same installation the stored key can be used. On a replacement installation, provide the recovery key when importing or restoring the encrypted archive.

Important limits

If both the original server and the separately stored recovery key are lost, the encrypted archive cannot be restored. If the host lacks the required encryption support, the plugin reports an error and does not present an unencrypted result as a successful encrypted backup.

Turning encryption off affects only future archives. Unencrypted backups still contain sensitive site data and require private storage and access control.

Restore and migration

Importing an archive adds a recovery point; it does not restore the website automatically.

1. 1
   Prepare

   Choose the correct full Lodone ZIP and download an independent copy. Prefer a staging rehearsal before restoring a live site.

2. 2
   Import if necessary

   In Backups, choose the archive and select Upload and verify. Chunked upload supports interrupted transfers. Wait for a completed history record.

3. 3
   Reduce concurrent writes

   Avoid new orders, account changes and form submissions during restoration. Use a maintenance window suitable for the website.

4. 4
   Confirm restore

   Read the overwrite warning, tick the confirmation and choose Restore for the intended backup. A full safety backup is created before the restore proceeds.

5. 5
   Follow progress

   Wait for verification, files and database work to finish. Keep the page open during the active operation and inspect errors before retrying.

6. 6
   Test and preserve evidence

   Check administrator login, pages, media, permalinks, forms and checkout. Retain both the source archive and the safety copy.

What changes during a restore

Restoration writes archive content into wp-content and imports the database. Migration logic handles supported database-prefix, URL and path replacements, including serialised values. Cache and host-specific generated files are handled separately. Root files are not automatically overwritten by a normal content/database restore.

Do not assume a restore removes every extra file already present on the target. A clean destination is preferable after a suspected compromise. Unusual plugins, absolute links embedded in custom code and external services need site-specific verification after migration.

Recover after server loss

You need an accessible off-server archive and a new working WordPress installation.

1. 1
   Find the independent copy

   Retrieve the recent full ZIP from outside the lost server. A copy kept only on the lost server cannot help.

2. 2
   Prepare the target host

   Use the recorded WordPress version as the starting point. Create a new database and a new wp-config.php with target-host credentials and new authentication salts.

3. 3
   Install and license Lodone

   Install the plugin on the target. Assign the licence to that domain in the customer account and activate it.

4. 4
   Import and restore

   Open Backups, upload and verify the full archive, then confirm Restore. Allow the safety-backup and restore phases to finish.

5. 5
   Review configuration

   Read the safe configuration template and apply only appropriate settings. Inspect archived .htaccess, robots.txt and web.config before optionally restoring selected roots in Backups > Recovery.

6. 6
   Re-enter protected credentials

   New authentication salts can make previously encrypted SMTP, WebDAV, cloud or AI credentials unreadable. Re-enter protected credentials, reconnect cloud accounts and test the integrations.

7. 7
   Validate the website

   Test login, permalinks, media, forms, email, scheduled tasks and payment integrations. Check a controlled order flow before reopening a store.

Optional root-file restoration

In Recovery, choose the full backup and select only the available root files you have reviewed for the new host. Confirm the overwrite. Recorded root checksums are checked and a full safety copy is created first. An Apache rule file is not automatically appropriate for a different web-server configuration.

Verification and external export

Understand what the checks prove and what remains your responsibility.

Manual export to an existing WebDAV folder

1. 1
   Configure

   In Backups > Recovery, enter your public HTTPS WebDAV folder, username and password. Enable manual export and confirm the configuration.

2. 2
   Export

   Select a completed full backup and confirm Export selected copy. The archive is streamed to the configured folder; the local copy is retained.

3. 3
   Verify externally

   The interface records a successful upload response. Open your storage, check the file and preferably retrieve it for a checksum or archive check.

WebDAV remains optional manual export. Automatic Dropbox transfers use the separate Cloud storage tab after you connect your own account and enable uploads. It creates no storage subscription. You must supply an existing reachable destination and sufficient quota. The implementation requires cURL, a public IPv4-resolvable host, valid TLS and a WebDAV endpoint that accepts the upload without redirects.

Storage passwords are encrypted using the installation security keys. Re-enter them after migration to an installation with new salts. An upload failure leaves the local archive available; do not treat a failed export as an external recovery copy.

Connect your Dropbox account

Your website sends backups to your own Dropbox account and storage.

1. 1
   Connect

   With an active licence, open Backups > Cloud storage and choose Connect account under Dropbox. Sign in to your own Dropbox and review the requested access. Return to the same signed-in WordPress administrator session over HTTPS.

2. 2
   Enable automatic uploads

   Select Automatically upload new backups. Connecting the account alone does not turn this on. Choose Keep latest cloud copies (1-100; default 10) and whether to email the site administrator after repeated failure. Select Save preferences.

3. 3
   Set creation separately

   Open Schedule and retention. Choose Daily, Weekly or Monthly, then the time in the WordPress site time zone and local retention. Save the schedule. Upload settings do not by themselves create new backups.

4. 4
   Confirm automatic scheduling

   Return to Cloud storage and check Automatic scheduling. Active - central connection is working means the eligible site is registered and a recent central check reached it. No hosting cron configuration is needed for this setup.

5. 5
   Verify the first copy

   Create a full copy or choose a completed existing copy and Add to upload queue. Wait for Uploaded and 100%. Open Dropbox, locate the archive in the Lodone app folder and retrieve it to verify the file.

Access, storage and account ownership

The configured Dropbox integration is restricted to its application folder. Review this scope on the consent screen. The app folder name follows the registered application name, Lodone Backups. Each customer authorizes their own account; the Lodone owner registers the integration once, and customers do not need to create API keys.

Your Dropbox quota, account policy and service availability apply. The plugin does not supply a storage subscription. Automatic cloud uploads support Dropbox and Nextcloud; manual WebDAV export is a separate workflow.

Connect your Nextcloud account

Send backups directly to your own Nextcloud storage.

1. 1
   Prepare your account

   Use your own Nextcloud account with enough available space. Lodone does not supply storage. A provider may offer a free allowance; account terms and quotas belong to that provider.

2. 2
   Copy the WebDAV URL

   In Nextcloud Files, open Settings and copy the WebDAV address. It must be a public HTTPS URL ending in /remote.php/dav/files/your-account-id/. Do not use the dashboard address.

3. 3
   Create an app password

   In your Nextcloud account security settings, create a dedicated app password for Lodone. Use the account username and this app password, rather than sharing your main login password.

4. 4
   Connect in Lodone

   Open Backups > Cloud storage > Nextcloud. Enter the WebDAV URL, username and app password, then select Connect and check. Confirm that the connected state appears.

5. 5
   Enable automatic upload

   Select Automatically upload new backups, choose how many cloud copies to keep and optionally enable failure email notifications. Save the settings. Connecting alone does not enable automatic uploads.

6. 6
   Choose the backup schedule

   Save a Daily, Weekly or Monthly backup schedule if you also want automatic creation. To transfer an existing completed copy, select it and add it to the upload queue.

Nextcloud uploads, progress and recovery

Backup creation and remote upload are separate operations.

Nextcloud uploads run in the background in resumable chunks. You may leave the cloud screen after queuing a completed copy. Progress, queue length and the most recent status are retained. A connected account or a partially uploaded file is not a completed remote backup.

To recover after server loss, download a completed archive from your Nextcloud account, prepare WordPress and activate Lodone, then upload, verify and restore the copy through Backups. Supply the separate recovery key for an encrypted archive.

Automatic scheduling without visitors

The Lodone service wakes WordPress; archive creation and transfer stay on your website.

Read the Automatic scheduling panel

Active confirms the connection, not a finished backup. The site, cron endpoint and connected storage must remain reachable. Hosting limits and outages can delay jobs. WordPress scheduling remains a fallback, which can also be delayed without visitors or host cron.

Dropbox operation and recovery

Review upload progress separately from backup creation and central connection status.

Upload evidence and recovery

Before transfer, the archive is checked against its stored SHA-256. Completion requires a provider file ID and matching remote byte size. A lost final response may be reconciled by unique filename and size. Uploaded is transfer evidence; retrieve a copy for independent checksum/archive verification.

Dropbox receives the website-produced archive: AES-256 encrypted only when that setting was enabled. Preserve the separate key for encrypted copies. After server loss, retrieve the archive and follow the import/restore procedure. Protected restoration still requires an active licence.

Cookie scan and coverage

The scanner discovers public URLs and continues in batches; the previous small-page scan limit no longer defines the queue.

1. 1
   Start

   Open Cookies > Overview and scan, then select Scan website.

2. 2
   Allow discovery

   The queue collects public posts, pages, products and other public post types, taxonomy and post-type archives, conventional sitemaps and linked same-site public pages.

3. 3
   Inspect progress

   Read checked/discovered URL counts, failed URLs and unchanged content. Discovery can add URLs while a job runs.

4. 4
   Resolve failures

   Inspect every failed URL and reason. Correct reachability, response or sitemap issues, then rerun the scan.

5. 5
   Review services

   Open Declaration, classify detected services and verify the live website before enabling consent.

Later scans and continuation

The job is saved between requests. Cron and the open administration screen advance it in bounded work units. Scan website resumes an active queue. On a new run, unchanged content can skip repeated classification using a fingerprint of returned HTML and cookie headers; requests still have to retrieve the content. Select Inspect unchanged content again when you need a fresh classification pass.

Coverage has a specific meaning

The denominator is the discovered public URL list, not proof that every possible route or visitor state was inspected. Private/password-protected content, login-only journeys, JavaScript-only routes and external hosts are outside that list. Scanned requests do not perform authenticated purchases or execute page JavaScript.

Responses exceeding the inspection limit, failed requests and unsupported redirects are reported. The scanner uses the current website host and port; routes on a separate host are not silently included. Review a catalogue of important journeys, especially contact forms, embeds, product, cart, checkout and account pages.

Compare consent in the browser

Run the page JavaScript on selected public same-site URLs in an isolated browser context.

1. 1
   Prepare

   Use a supported Chrome or Edge browser. Open Cookies > Overview and scan > Compare in browser. Review the selected public URLs; one run supports up to 20.

2. 2
   Start and keep the tab open

   Run the comparison. Each URL is loaded in isolated frames for Before consent, Reject all and Accept all. The probe observes resources and storage names, and scrolls to trigger some lazy content.

3. 3
   Inspect phase differences

   Recognised optional services observed before consent or after rejection require investigation. Services may load after acceptance. Unknown observations are for manual review, not automatically a pass.

4. 4
   Read completeness

   Unsupported browser isolation, frame/CSP failures, missing consent actions and timeouts produce incomplete results. Correct the cause before relying on the comparison.

5. 5
   Preserve and retest

   Results remain visible after reload. Review important desktop/mobile journeys and rerun after changing scripts, tags, consent settings or cache behaviour.

Blocking and banner configuration

Connect service classification, prior blocking and visitor choices.

What the blocker can and cannot do

Server-side inspection identifies scripts, embeds, known markers and cookie response headers. The live blocker also observes recognised resources inserted into the visitor page. This improves handling of dynamic additions, but it is not a guarantee that arbitrary custom tracking code is understood. The separate browser comparison executes page JavaScript on selected public URLs within its documented observation window.

A recognised-service block does not stop every possible server-set cookie, custom inline request, third-party tag configuration or storage mechanism. Review unknown services and test real browser network/storage behaviour. Cache, tag-manager and script-delay settings can affect when consent code runs.

Cookie languages and page selection

Choose automatic language handling or a fixed language for consent content.

At the top of Cookies > Settings, use the separate administration-language and public-language dropdowns. Automatic administration language follows the WordPress backend language. Automatic public language follows the website locale. A manual choice overrides the corresponding automatic setting. Save cookie settings at the bottom.

The cookie banner and generated cookie declaration support all 24 official EU languages: Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Irish, Italian, Latvian, Lithuanian, Maltese, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish and Swedish. This does not translate the website content or third-party plugins.

The selected public language applies to consent labels, category descriptions and generated declaration wording. Check any custom banner text you entered yourself and review the public page after changing language.

1. 1
   Choose the declaration page

   The WordPress privacy-policy page is selected by default. Pick another published page in the page dropdown if preferred.

2. 2
   Save general settings

   Select Save cookie settings at the bottom. Open the chosen public page to review the generated list.

3. 3
   Classify services

   Changing a category in Declaration saves that individual selection automatically. Wait for confirmation. General settings and the page/language selection still require their save button.

Declaration and consent evidence

Review classifications rather than assuming the scanner knows every purpose.

<b>Necessary</b> covers essential sessions, security, cart and consent choices and is always active. <b>Functional</b> covers optional functions and embeds. <b>Statistics</b> covers usage analytics. <b>Marketing</b> covers advertising measurement and personalisation.

Changing a service category in Declaration saves that category automatically. Wait for the saved confirmation; if saving fails, correct the error and retry. General cookie settings use their own Save cookie settings button at the bottom.

Visitor controls

Evidence and publication

Consent log shows recorded actions, category choices, policy version and timestamps. Use Download CSV proof log for an audit export. Consent identifiers are stored as one-way SHA-256 hashes; the consent log does not store raw IP addresses or browser identifiers. Other WordPress plugins or the host may maintain their own logs.

Use the shortcode displayed by the Declaration tab to place the generated service list on a page, or enable the optional append on the selected privacy page. The generated list does not replace a privacy notice that explains the actual processing and relevant parties.

Security checks and login guard

Review the assessment, then enable only protections appropriate to the site.

Run security check evaluates signals such as HTTPS, WordPress/plugin updates, PHP, exposed debug settings, file editing, login controls, headers, administrator accounts, email 2FA and available recovery copies. Passed means the particular check found the expected state at that time; it does not mean that the whole site is secure.

Activity records

Security activity includes plugin activation/deactivation, administrator creation, user-role changes and selected important setting changes. The logs also contain module operation results. It is a selected event history, not a complete forensic record of every server or WordPress action.

Malware scan, quarantine and request firewall

Inspect suspicious code and request patterns without treating every match as a confirmed compromise.

1. 1
   Run and review

   Open Security and start the malware-pattern scan. Review each path, matched pattern, context and risk level. A match is evidence to inspect, not a malware verdict.

2. 2
   Quarantine deliberately

   For a reviewed suspicious file, confirm the action. Lodone first requires a completed full safety backup, then moves only that file and records a restorable quarantine entry.

3. 3
   Test the website

   After quarantine, check administration and the affected public features. Restore the exact item from the quarantine list if an authorised feature breaks, then investigate its trusted source.

4. 4
   Configure and monitor

   Enable the optional request firewall only after review. Test forms, API callbacks, uploads and checkout; then monitor security events and rate-limited email alerts.

Coverage and limits

The scanner covers supported plugin, theme and uploads files for suspicious PHP constructs, encoded payloads, backdoor-style indicators and executable uploads. Exclusions reduce known false positives but cannot prove that a file is safe.

The firewall blocks selected suspicious request patterns inside WordPress and can protect executable uploads. It does not filter traffic before PHP or replace hosting/CDN protection, a vulnerability database or a complete antivirus engine.

File integrity and approved baseline

Compare core with official hashes and plugin/theme changes with a reviewed local reference.

1. 1
   Run Check files

   Open Security > File integrity. The job requests official checksums for the installed WordPress version and locale, then reads files in batches.

2. 2
   Review the report

   Inspect official core matches, core differences, new/changed/removed files, unreadable paths and any checksum-download error.

3. 3
   Approve a baseline carefully

   On a reviewed installation, confirm Create approved baseline. It is saved only after successful core verification and without core differences or unreadable paths.

4. 4
   Schedule and alert

   Optionally enable weekly checking and email changes to the WordPress administrator. Save the schedule and test email delivery.

Coverage and trust

The scan covers wp-admin, wp-includes, plugin and theme directories, root PHP files except wp-config.php, and additional official core-manifest entries. It skips symbolic links. It is not a recursive scan of every uploads file, custom directory, wp-config.php setting or server file.

Core uses the official WordPress checksum reference. Other scanned files use local SHA-256 values. The baseline has an authentication signature tied to WordPress salts; changing salts can invalidate it. A plugin or theme baseline says what existed at approval time, not whether that code is free from malicious logic.

Responding to differences

Expected updates can create many legitimate changes. Compare paths with the intended update and obtain clean files from trusted sources when a core difference is unexpected. Investigate before approving a replacement baseline. Creating a new baseline replaces the comparison reference and can hide previously unexplained changes.

Database maintenance

Remove reviewed obsolete records, with a full safety copy before deletion.

Open Security > Database and select Analyze database. Analysis is read-only. It creates a temporary reviewed batch for the current administrator; select the categories you intend to remove and confirm only after reading the records and counts.

1. 1
   Review

   Select only the eligible categories you understand. The analysis snapshot expires after 30 minutes.

2. 2
   Back up and clean

   Confirm the action. Lodone first creates a full backup; deletion proceeds only after that succeeds.

3. 3
   Read actual counts

   Eligibility is rechecked against the reviewed records. Reported removals can be lower than the analysis count if records changed.

4. 4
   Repeat if needed

   Run a new analysis for another batch. Keep the safety-backup ID and verify the site after cleanup.

SMTP setup and delivery

Confirm receipt in the intended mailbox before relying on alerts or email challenges.

1. 1
   Configure SMTP

   Enable authenticated SMTP. Enter server hostname, port, SSL/TLS setting, username, password and permitted sender address/name. Follow your mailbox provider configuration.

2. 2
   Save and test

   Save settings, enter an accessible test recipient and send a test email. Check both the operation report and receipt in the destination mailbox.

3. 3
   Verify user email

   Check the WordPress user profile address for each user who will receive a login code. The SMTP sender is not automatically the code recipient.

Delivery and coverage boundaries

A successful send means the transport accepted the operation; it does not prove inbox placement. Check spam, mailbox filters and the actual recipient address. The challenge applies to supported interactive WordPress login; API/application-password paths are not a universal email-2FA barrier.

Email two-factor authentication

Protect supported interactive login with a second email-code step.

1. 1
   Prepare delivery and recovery

   Complete SMTP setup and receive the test message. Check the protected user's actual WordPress email address. Keep a tested administrator recovery path.

2. 2
   Enable for the user

   In the Security two-factor section, select Enable for the intended account after the successful SMTP test.

3. 3
   Test a fresh login

   In a separate signed-out session, enter the account password, receive the email code and select Confirm login.

4. 4
   Review the outcome

   Confirm that the code goes to the protected user and that a correct challenge allows login. Do not protect every administrator until this workflow works.

Know the protected entry point

The email challenge applies to supported interactive WordPress login. API and application-password paths are not a universal email-2FA barrier. Maintain strong credentials and manage alternate application access independently.

Known vulnerabilities and daily checks

Compare installed component versions with a current advisory feed and automate recurring review.

1. 1
   Configure the feed

   Open Monitoring > Automation and enter a Wordfence Intelligence API feed key. The key is stored encrypted on this WordPress installation.

2. 2
   Run the first check

   Open Monitoring > Vulnerabilities and select Check now. Installed WordPress, plugin and theme versions are compared with the current scanner feed.

3. 3
   Read each finding

   Review risk, component, installed version, advisory title and the recommended patched version. If no patched version exists, disable and replace the affected component after testing.

4. 4
   Enable daily checks

   In Automation, enable daily checks, set the report email and save. The background job also starts the malware-pattern scanner.

5. 5
   Verify the schedule

   Review the displayed next-run time and confirm that a later report has a new timestamp. WordPress scheduled execution must be working.

Alerts and interpretation

Email is sent only when a new problem is found or an automated check fails. No email is not proof that a scheduled run happened; inspect the stored check time and reports. A feed result describes known published vulnerabilities associated with the detected version. It does not prove exploitability on this site or detect every unknown weakness.

Update or replace affected components through a controlled workflow: create a recovery point, review compatibility, apply the trusted update, clear caches and rerun both the vulnerability and malware checks. Do not treat a clean advisory report as a penetration test or a substitute for supported software and hosting controls.

Performance audit and safe profile

Use one page-cache owner and test the public website after changing delivery.

Run performance check requests the front page twice and reviews internal response time, caching, compression, browser-cache signals, HTML size, initial CSS/JavaScript, autoloaded options and object-cache signals. The summary is Lodone findings, not a public PageSpeed or Core Web Vitals score. An internal request does not represent every visitor device or network.

Dynamic-request protection

Recognised cart, checkout, account, session, callback, AJAX, REST and logged-in requests bypass the page cache. Keep ecommerce protection in place and test your own custom dynamic routes. Do not cache personalised output merely because the generic front page works.

Browser performance history

Save comparable before-and-after results from the device and connection used for the test.

1. 1
   Prepare a consistent test

   Use the same browser, device, connection and cache state for comparisons. Close unrelated heavy tasks and test a representative public home page.

2. 2
   Run the browser test

   Open Performance > Browser test and start the measurement. Lodone loads the public home page and records the result locally in WordPress.

3. 3
   Read the metrics

   Review LCP, CLS, TTFB, DOM ready, full load time, resource count, transferred data and oversized-image count.

4. 4
   Compare carefully

   Apply one intended optimization, clear relevant caches and repeat the test. Use the saved history and before/after comparison with consistent conditions. Inspect forms, account and checkout separately; a faster home page does not prove every route improved.

Optimize selected images or all media

Choose scope, format and compression, then explicitly approve processing.

1. 1
   Open Image optimization

   Go to Performance > Image optimization. Resolve any warning about an active overlapping image optimizer.

2. 2
   Choose the scope

   Entire media library includes supported media attachments and their registered thumbnails. Only selected images uses the selected items in the displayed list.

3. 3
   Choose the output

   Keep original format, WebP or AVIF. Choose Lossless or Smart compression; smart processing can alter pixel detail.

4. 4
   Confirm the transfer

   Read and tick the approval for external image processing, including thumbnails. Select Optimize images.

5. 5
   Follow the job

   Discovery prepares the library; processing advances through file-size tasks. Inspect the progress and errors. Use Resume if the active job needs another step.

6. 6
   Inspect the public result

   Compare representative photos, text in graphics, transparent images and product details. Check mobile and desktop, then clear relevant page caches.

Supported inputs and safe writes

Local JPEG, PNG, WebP and AVIF attachments are supported. Each source must fit the supported per-file size limit and contain no more than 40 megapixels. Files must be inside the local WordPress uploads directory; linked external files are rejected. GIF, SVG, remote media and arbitrary theme assets are outside this optimization workflow.

A whole-library run records the highest eligible attachment ID at the start. Later uploads are handled only if future-upload automation is enabled, or by another manual run. Successful writes preserve an original first. Returned output is checked for expected format and unchanged dimensions; an output that is not smaller is not committed.

Progress, savings and restoration

Current-job statistics and Total results answer different questions.

A savings example

If selected optimized outputs are 60% of the size of the represented originals, the reported savings are 40%. This describes payload sizes, not total server disk reduction. Preserved originals and format variants consume additional disk space. Removing files, restoring originals or changing selected output can change Total results.

Delivery and rollback

Smaller WebP/AVIF variants are inserted through the standard WordPress attachment-image filter with an original fallback. CSS backgrounds, custom HTML, some builders and external/CDN image rendering may need theme integration. A generated variant is not proof that every page serves it.

To undo an optimized attachment, locate it in the image list, confirm and select Restore originals. Lodone checks preserved-original hashes, restores the original file and thumbnails and removes its recorded variants. The totals then reflect the remaining optimized media.

SEO and GEO: expanded audit

Improve technical information while retaining editorial responsibility.

The 21-check audit reviews indexing, titles, descriptions, H1 use, internal links, redirects, sitemap, robots, canonicals, Open Graph, Schema, identity, image ALT, content depth, author context and generative-search readiness. It does not guarantee search or AI inclusion.

Write for the actual page

Use a specific title and an accurate summary. A blank Lodone title falls back to the WordPress title. Use a canonical override only when another URL is the intended primary version. Check no-index choices carefully; they are requests to search engines, not access controls.

The audit recognises supported Yoast descriptions and uses rendered content and headings where available. Account, registration, test and lesson pages are not treated as ordinary short articles. Review the remaining content findings individually; a word-count warning alone is not an instruction to expand every page.

Optional AI text generation

Generate in small reviewed batches and inspect the public changes.

1. 1
   Prepare a recovery point

   Create and download a full backup before a run that can change metadata or image ALT.

2. 2
   Configure the optional service

   In SEO/GEO settings, enter your own OpenAI API key, a compatible model and a conservative pages-per-run setting. Save.

3. 3
   Review eligible content

   Run the audit and inspect public content. Decide whether previously stored Lodone SEO text may be overwritten.

4. 4
   Confirm the action

   Select Generate and apply professional SEO text (AI). Read the data-transfer warning and approve only the intended processing.

5. 5
   Review the report

   Inspect changed, failed and skipped items. Open important page editors and check generated titles, descriptions and ALT against the actual content.

6. 6
   Inspect rendered pages

   Review public source/output after cache purge and correct inaccurate, repetitive or inappropriate generated wording.

Inputs, ownership and cost

This optional workflow uses eligible public page text and supported public images needing ALT. It is not intended for private drafts, customer records or secrets. Your configured AI account is responsible for its service availability and usage charges. Image optimization and AI text generation are separate services with separate configuration.

The pages-per-run setting allows 1-20; smaller batches reduce timeout risk. The model field must match a model compatible with the integration. Availability can change; a rejected service request is reported rather than evidence that content was generated.

Google Search Console reporting

Connect read-only search performance data to the technical audit context.

1. 1
   Prepare Google OAuth

   Create suitable Google OAuth credentials, add the exact Redirect URI shown by Lodone and enable access required for Search Console reporting.

2. 2
   Save the connection settings

   Open Monitoring > Google Search Console. Enter the OAuth Client ID and client secret, then save. The client secret is stored encrypted on this WordPress installation.

3. 3
   Connect the owner account

   Select Connect Google Search Console, sign in to the account that can access the website property and approve the requested read-only access.

4. 4
   Choose and verify the property

   Confirm that the connected Search Console property represents the intended website. A domain-property and URL-prefix property can have different coverage.

5. 5
   Refresh and review

   Refresh data to display clicks, impressions, CTR, average position and top queries for the last 28 days. Disconnect when the integration is no longer needed.

How to use the data

Search Console results show observed Google Search performance; they do not prove that every public URL is indexed or healthy. Compare low-CTR queries with relevant titles and descriptions, and investigate material position or impression changes alongside the technical audit and actual page content.

The SEO/GEO audit evaluates all supported published public pages, posts and products instead of stopping at the former 250-item cap. It excludes attachments, selected template post types and sensitive WooCommerce system pages. Internal-link findings are capped for practical reporting, and rendered or custom application routes can still require separate checks.

Monthly SEO and GEO growth

A recurring improvement plan without paid AI credits.

1. 1
   Open Monthly growth

   Enable monthly reports in the Lodone Monthly growth section. Use Update monthly plan to collect the current findings manually.

2. 2
   Connect search data if needed

   To include actual Google results, configure and connect Search Console with an account that has access to the correct property. Adding a domain to Google alone does not connect Lodone.

3. 3
   Review this month's plan

   Review priorities based on technical SEO/GEO findings and, when available, pages with many impressions but few clicks or declining traffic. Open the affected page to make editorial corrections.

4. 4
   Check results again

   After making changes, update the plan to see which findings are no longer detected and which remain. Review saved monthly reports and tracked page changes.

5. 5
   Enable optional email

   Choose the report recipient and enable monthly email if wanted. A successful send status means the mail transport accepted the message; check delivery in the mailbox.

Search Console comparison uses the latest 28-day reporting window and the preceding 28 days. It can show clicks, impressions, CTR and average position where data is available. Without a connected property, the technical improvement plan still works but real search metrics are unavailable.

The plan and history do not require paid AI credits and do not rewrite content automatically. Optional AI text generation is a separate configured service with its own usage charges.

Compatibility and data handling

Know which actions stay local and which use an external connection.

Work alongside other plugins

Use one owner for page caching, public SEO markup and image optimization. Detection covers recognised providers, not every custom plugin. A conflict warning is a request to resolve overlapping features, not an instruction to uninstall an unrelated tool. Verify custom integrations and hosting cache layers separately.

Credentials encrypted with WordPress security keys protect stored values against simple database reading; they are not protection against full compromise of both database and configuration. Re-enter protected credentials after a move with new salts. Keep archives, CSV exports and support files private.

A practical maintenance routine

Keep evidence that recovery, privacy and protection continue to work.

Write down the operating result

Keep a short record: website and version, operation time, archive ID/checksum, important settings, errors and the pages tested. For image jobs, retain the error count and represented before/after sizes. For scans, retain discovered/checked/failed counts. For integrity, retain the baseline date and explanation for accepted changes.

Choose backup frequency according to how much new content or order data you can afford to lose. Choose alert recipients who can act on failures. A saved schedule or an Active central connection is not evidence that the scheduled archive completed. Inspect creation and upload results separately.

Troubleshooting: access and recovery

Start with the actual operation message and the relevant environment.

Troubleshooting: scan and optimization

A completed job still needs a review of failures and public behaviour.

Troubleshooting: monitoring

Check credentials, schedules and external-service coverage before repeating a failed request.

Site acceptance checklist

Use this to evaluate the plugin on a specific website, beyond reading the guide.