PW Security and Backup documentation
This documentation explains how to install, configure and use PW Security and Backup on a WordPress website. It covers login protection, WordPress security hardening, suspicious-code scanning, SHA-256 file integrity monitoring, manual full backups, selected-file recovery, traffic monitoring, security analysis, notifications and logs.
PW Security and Backup is designed to bring essential WordPress security and backup functions together in one administration panel. The plugin works inside your own WordPress installation and does not require a licence key, remote security account or external scanning service.
The plugin does not send telemetry, security scan results, traffic records, credentials or backup contents to Poyraz Web, PW Feed or another external service. Security-related information remains under the control of the website administrator and is stored according to the configuration of the WordPress installation and hosting environment.
No WordPress security plugin can guarantee complete protection against every attack, compromised credential, vulnerable extension or server failure. PW Security and Backup should be used as part of a layered website security and recovery strategy.
System requirements
Before installing PW Security and Backup, confirm that the website meets the following minimum requirements:
• WordPress 5.8 or later.
• PHP 7.4 or later.
• Permission to install and activate WordPress plugins.
• A writable WordPress uploads directory.
• Sufficient server storage for full backup archives.
• PHP ZipArchive support for creating ZIP backups.
• A working WordPress email configuration for notifications.
A current PHP version is recommended for improved security, performance and compatibility. The website should also use HTTPS to protect administrator sessions and information transmitted between the browser and the server.
If PHP ZipArchive is unavailable, the security and monitoring tools can continue to operate, but full ZIP backup creation will not work until ZipArchive support is enabled by the hosting provider.
Installing the plugin
PW Security and Backup can be installed through the WordPress administration panel.
- Sign in to the WordPress administration area.
- Open Plugins and select Add New Plugin.
- Select Upload Plugin.
- Choose the PW Security and Backup ZIP package.
- Select Install Now.
- Wait for WordPress to complete the installation.
- Select Activate Plugin.
After activation, a new PW Security menu appears in the WordPress administration area. The plugin’s main sections are available from this menu.
If the plugin is available through the WordPress Plugin Directory, it can also be installed by searching for PW Security and Backup on the Add Plugins screen.
Recommended first-time setup
Do not activate every restriction immediately. A staged setup makes it easier to identify compatibility or access problems.
The recommended initial configuration sequence is:
- Create a full website backup.
- Verify the notification email address.
- Review the Security Center.
- Configure failed-login protection.
- Review the allowlist and blocklist.
- Apply an appropriate security-hardening profile.
- Run the first suspicious-code scan.
- Review all reported findings.
- Confirm that the website is clean and working correctly.
- Create the initial SHA-256 file-integrity baseline.
- Configure scheduled health and integrity checks.
- Enable live traffic recording only if it is required.
Create an external backup through your hosting provider or another trusted backup system before making important login or server-rule changes. The plugin’s own manual backup can then provide an additional recovery point.
Using the Security Center
The Security Center provides a central view of the website’s current security condition. It displays the security score, latest scan information, critical findings, banned IP addresses, system health information and recent security events.
The security score is a practical configuration indicator. It helps identify missing protective settings, but it should not be interpreted as a guarantee that the website is secure.
The System Health section can report information such as:
• WordPress and PHP versions.
• HTTPS status.
• Debug mode status.
• XML-RPC protection.
• REST API user protection.
• PHP execution protection in the uploads directory.
• Latest file scan status.
• File-integrity status.
• Current security score.
The Tasks section lists items that may need administrator attention. Quick Actions provide direct access to common operations such as starting a security scan, checking file integrity, applying standard hardening, viewing banned IP addresses and opening the log system.
Review the Security Center after WordPress updates, theme changes, plugin installations, server migrations and other important website operations.
Configuring core settings
Open PW Security and select Core Settings to configure notifications, log retention and scheduled health checks.
Enter an email address that is actively monitored. Depending on the enabled options, the plugin can send notifications when:
• A file change is detected.
• An administrator signs in.
• An IP address is banned.
Email delivery depends on the WordPress mail system. If notifications are not received, check the site administrator email, spam folder, hosting mail restrictions and SMTP configuration.
The log retention setting controls how long security log records remain available. Choose a period that provides useful investigation history without allowing the WordPress database to grow unnecessarily.
Scheduled health checks can run at the following intervals:
• Every 6 hours.
• Every 12 hours.
• Every 48 hours.
• Weekly.
• Every two weeks.
• Monthly.
The recommended default interval is every 12 hours. High-activity websites may require more frequent checks, while smaller websites may use a longer interval.
WordPress scheduled events normally depend on WP-Cron. On low-traffic websites, an event may run later than its configured time. A real server cron can provide more consistent execution when supported by the hosting provider.
Configuring login security
Open Login Security to configure protection for the WordPress login process.
The available controls include:
• Login security activation.
• A custom login path.
• Hiding the standard /wp-login.php address.
• Returning a 404 response for unauthenticated /wp-admin access.
• An additional security password.
• Failed-login attempt limits.
• Attempt tracking windows.
• Temporary ban durations.
• Question-and-answer verification.
• IP allowlists and blocklists.
Configure these settings carefully because incorrect login-path or IP rules may prevent authorised administrators from reaching WordPress.
Changing the WordPress login path
The custom login-path feature replaces the commonly targeted login location with an administrator-defined path.
Use a path that is difficult to predict and contains only suitable URL characters. Do not reuse a password, email address, company name or easily guessed term as the login path.
Before enabling login-address hiding:
- Record the new login URL in a secure password manager.
- Open the new URL in a private browser window.
- Confirm that the login form is accessible.
- Test access with an authorised administrator account.
- Keep hosting file-manager or FTP access available during the change.
The new login path reduces exposure to basic automated requests, but it is not a replacement for strong passwords, multi-factor authentication or failed-login protection.
Using the additional security password
The additional security password adds another verification field to the WordPress login form.
Choose a password that is different from the WordPress account password. Store it securely and share it only with authorised users.
Leaving the new-password field blank preserves the currently configured additional password. If the password is changed, verify the new login process before closing the existing administrator session.
This feature adds another access layer but does not replace individual WordPress accounts or secure account-password practices.
Setting failed-login limits
The failed-login controls determine how many unsuccessful attempts are allowed, how long attempts are counted and how long an IP address remains banned.
A very low limit may block legitimate users who mistype their passwords. A very high limit provides less resistance against repeated automated attempts.
The appropriate values depend on the website, number of authorised users and normal login activity. Review the Failed Login Attempts table after enabling protection to confirm that the rules behave as expected.
Temporary bans appear on the Banned IP screen. An authorised administrator can review the reason, start time, end time and attempt count, and can remove a ban when necessary.
Using question-and-answer verification
Question-and-answer verification adds a custom challenge to the login form.
Use a question whose answer is known to authorised users but is not publicly available on the website or easily discovered through company information and social media.
Avoid questions such as the company name, domain name, city or other information already displayed publicly. The answer should be stored securely with the other website access information.
Managing the IP allowlist and blocklist
Enter one IP address per line in the relevant field.
Allowlisted IP addresses are excluded from automatic bans. Add an address only when it is trusted and reasonably stable. Be careful with dynamic residential addresses because the address may later be assigned to another user.
Blocklisted IP addresses receive a 404 response across the website. Confirm the exact address before adding it. Never add an IP address if you are unsure whether it belongs to the administrator, hosting provider, monitoring system or another essential service.
If the website uses a reverse proxy, content delivery network or load balancer, verify that WordPress receives the correct visitor IP information before relying on IP-based restrictions.
Applying WordPress security hardening
The Security Hardening screen provides Basic Protection, Standard Protection and Maximum Protection profiles. It also allows supported settings to be reviewed and applied individually.
Hardening controls may include:
• XML-RPC protection.
• REST API user-list protection.
• Author-enumeration protection.
• Directory-listing protection.
• Blocking PHP execution in the uploads directory.
• Related WordPress and server configuration protections.
Standard Protection is generally the most appropriate starting point for a typical WordPress website. Maximum Protection may affect integrations or specialised website functions and should be tested before use on a live website.
For example, disabling XML-RPC may affect services or applications that depend on it. REST API restrictions may affect a theme, plugin, headless application or external integration.
The Changes and Rollback area records supported hardening actions. Rules written by the plugin can be reversed when rollback is supported. Test important changes in a staging environment whenever possible.
Running a suspicious-code scan
Open File Scanner and select Start Scan to inspect WordPress files for potentially risky patterns.
The scanner reviews important areas including WordPress core directories, themes, plugins, uploads and critical configuration files. It can identify patterns associated with suspicious PHP code, webshell filenames, command-execution functions, hidden iframes, obfuscated code and other items that require examination.
A scanner result is not a final malware diagnosis. Legitimate plugins, themes and custom code may use functions that also appear in unsafe software.
For every finding, review:
• The risk level.
• The file path.
• The reported code or line.
• The finding description.
• The source of the file.
• Recent plugin, theme or WordPress updates.
• Whether the same file exists in a verified original package.
Do not delete or quarantine a file solely because it appears in the results. Confirm the finding first.
Ignoring verified findings
If a finding belongs to trusted and verified code, it can be added to the ignored-findings list.
Add a clear note explaining why the item was ignored, such as “Verified against the original plugin package.” This helps another administrator understand the decision later.
Ignored findings remain recorded and can be returned to the active findings list. Review ignored items after software updates because the file or code may have changed.
Using quarantine
Quarantine moves selected files to a protected location below the WordPress content directory.
Use quarantine only after confirming that the file is suspicious and is not essential to WordPress, the active theme or an important plugin. Quarantining an essential file may cause a fatal error, disable a feature or make part of the website unavailable.
Before quarantining a file:
- Create a current backup.
- Record the complete file path.
- Compare the file with a clean original copy.
- Confirm that the website can operate without the file.
- Keep hosting file-manager or FTP access available.
Professional malware assistance may be required when the purpose of a file cannot be determined safely.
Creating a file-integrity baseline
File Integrity uses SHA-256 signatures to detect modified, newly added and deleted files and directories.
Create the initial baseline only after confirming that the website is clean and functioning correctly. The baseline represents the trusted state against which later checks are compared.
Do not create a new baseline simply to remove unexplained warnings. First investigate every unexpected change. Otherwise, an unauthorised file may become part of the trusted reference.
A new baseline may be appropriate after:
• A verified WordPress core update.
• A verified plugin or theme update.
• Approved custom development work.
• A controlled website migration.
• A completed incident response and clean-up process.
Large websites are processed in smaller portions to reduce server load and timeout risk. The complete result becomes available after all scan portions have finished.
Reviewing integrity findings
Integrity results may classify changes as:
• Modified file.
• New file.
• Deleted file.
• New directory.
• Deleted directory.
A reported difference does not automatically indicate malicious activity. Updates, cache operations, image optimisation, maintenance tools and authorised development may change website files.
Compare the time of the reported change with update logs, administrator activity and hosting records. Investigate changes that cannot be explained by an authorised operation.
When file-change notifications are enabled, the plugin sends a summary through the configured WordPress email system after the integrity process completes.
Creating a full backup
Open Backup and select Create Full Backup.
The plugin creates a ZIP archive containing WordPress files and database tables. The archive is stored in a randomly named, protected directory below the WordPress uploads directory.
Full backup creation is manual in the current version. Scheduled health and integrity checks do not create automatic backup archives.
Before creating a backup, confirm that:
• PHP ZipArchive is available.
• The backup directory is writable.
• The server has sufficient free disk space.
• The website is not undergoing a major data import or update.
• The browser page can remain open while the process runs.
Large websites may require several minutes and significant temporary storage. Do not close the page while backup creation is in progress.
Managing backup archives
The Server Backups area displays the filename, creation date, size and available actions for each archive.
Available actions include:
• Download.
• Compare Files.
• Delete.
Download important backups to a secure location outside the website’s hosting account. A backup stored only on the same server may be lost during a hosting failure, account suspension, storage failure or serious compromise.
Protect downloaded backups carefully because they may contain personal data, account information, configuration values and other sensitive website content.
Deleting a backup from the server is permanent. Confirm that another verified copy exists before deleting an important recovery point.
Comparing current files with a backup
Select Compare Files to compare the current website files with the selected backup.
The comparison can identify files that are changed, missing or newly present. Use this information to understand what has changed since the backup was created.
A difference may result from a legitimate update, content operation, cache process or authorised edit. Review the file path and change context before restoring or deleting anything.
Restoring selected files
PW Security and Backup provides selected-file recovery from a backup comparison.
The operation replaces the current file with the version stored in the selected backup. It is not a complete one-click website or database restoration system.
Before restoring a file:
- Confirm that the backup belongs to the current website.
- Confirm that the selected backup contains the required file version.
- Create a current recovery copy.
- Check whether the file has received legitimate updates since the backup.
- Consider testing the restored version in a staging environment.
Restoring an older plugin or theme file into a newer software version can create incompatibility or security problems. Use selected-file recovery only when the relationship between the backup and current software version is understood.
The comparison screen can also offer deletion for a current file that does not exist in the selected backup. This action is permanent and should be used only after confirming that the new file is unwanted and safe to remove.
Using live traffic monitoring
Live Traffic records a limited local history of website requests and can classify normal, bot and potentially suspicious activity.
The screen provides information such as:
• Requests during the last 24 hours.
• Unique IP addresses.
• Bot requests.
• Suspicious requests.
• Recent request records.
• Most active IP addresses.
• HTTP method distribution.
Live traffic recording is disabled by default. Enable it only when the information is required and after considering website traffic volume, database growth and applicable privacy obligations.
Recorded data may include request paths, IP addresses, request methods, referrers and user-agent strings. The records remain inside the WordPress installation and can be cleared from the plugin screen.
Traffic classifications are indicators. A request marked as suspicious is not automatically proof of an attack.
Using Security Analysis
Security Analysis combines available security information into an overall assessment.
The screen can display:
• Analysis status.
• Security score.
• Risk score.
• Priority risk.
• Overall assessment.
• Priority action list.
• Analysis metrics.
• Risk records.
• Latest log summary.
Select Refresh Analysis after completing a scan, integrity check or important configuration change. The report can also be downloaded in TXT format for review or record-keeping.
The report is intended to support administrator decisions. It does not replace a professional penetration test, server audit or malware investigation.
Reviewing logs
The Log System records important plugin operations and security events.
Log entries may contain:
• Date and time.
• Event type.
• Event description.
• IP address.
• Related WordPress user.
Logs can be exported as a CSV file for authorised analysis. They can also be cleared from the administration screen.
Choose a suitable retention period and protect exported log files because they may contain security-related and personal information.
Emergency recovery
If a login-path or security configuration problem prevents access to the WordPress administration area, use the hosting file manager or FTP to rename the plugin directory.
Original directory:
/wp-content/plugins/pw-security-and-backup/
Example temporary name:
/wp-content/plugins/pw-security-and-backup-disabled/
WordPress will no longer load the plugin under its expected path. After regaining access, investigate the relevant setting before restoring the original directory name and reactivating the plugin.
Keep a current backup and hosting-level access information available before making important login or hardening changes.
Updating the plugin
Create a backup before installing an important plugin update.
A normal WordPress update preserves existing settings, logs, security information and backup archives. After updating:
- Confirm that the plugin is active.
- Open the Security Center.
- Review the current security status.
- Test the login process.
- Check scheduled health settings.
- Run a file scan or integrity check when appropriate.
- Confirm that email notifications still work.
Do not install an older version over a newer version unless there is a specific recovery reason and the compatibility effects are understood.
Deactivation and uninstall
Deactivating the plugin stops its active WordPress hooks and scheduled tasks but normally preserves settings and stored information for later reactivation.
Uninstalling the plugin from the WordPress Plugins screen removes plugin settings, reports, logs and scheduled events.
Backup ZIP files are deliberately preserved during uninstall so that removing the plugin does not destroy recovery data. These archives may still contain sensitive information and should be downloaded, retained or manually removed according to the administrator’s backup policy.
Privacy and local data
PW Security and Backup does not send telemetry, scan results, credentials, traffic records or backup contents to Poyraz Web, PW Feed or another external service.
Depending on the enabled features, the local WordPress installation may store:
• Security event records.
• IP addresses.
• WordPress usernames.
• Login-attempt information.
• Request paths and user-agent information.
• File-integrity signatures.
• Scan findings.
• Quarantine metadata.
• Backup archives.
Website administrators are responsible for informing users where required, limiting access to this information and following applicable privacy, retention and data-protection requirements.
Recommended maintenance routine
A practical maintenance routine includes:
• Review the Security Center regularly.
• Keep WordPress, plugins and themes updated.
• Run a suspicious-code scan after important changes.
• Review unexplained integrity findings.
• Create a full backup before updates or configuration changes.
• Download important backups to secure external storage.
• Check failed-login attempts and active IP bans.
• Review ignored scan findings periodically.
• Confirm that email notifications are delivered.
• Remove unused administrator accounts, plugins and themes.
• Test emergency access and recovery procedures.
• Review privacy and log-retention settings.
Common questions
Does PW Security and Backup automatically fix every security problem?
No. Some reversible hardening settings can be applied through the plugin, but suspicious files, compatibility issues and security incidents require administrator review.
Does the plugin create scheduled backups?
No. The current version creates full backups manually. Scheduling applies to health and file-integrity checks.
Does a scanner finding mean that the website contains malware?
No. A finding identifies code or a file that requires investigation. Legitimate software can sometimes use functions that also appear in unsafe code.
Can the plugin restore the entire website automatically?
No. The current administration interface provides backup comparison and selected-file recovery. Full database or complete website restoration may require hosting tools or professional assistance.
Where are backup files stored?
They are stored in a randomly named, protected directory below the WordPress uploads directory. Important backups should also be downloaded and stored outside the same hosting account.
Does the plugin send website data to PW Feed or Poyraz Web?
No. The plugin does not send telemetry, security results, traffic records, credentials or backup contents to PW Feed or Poyraz Web.
What should be done after a legitimate software update?
Run the appropriate security checks, review the changed files and create a new integrity baseline only after confirming that the updated website is clean and functioning correctly.
Getting support
Before requesting support, collect the following non-sensitive information:
• WordPress version.
• PHP version.
• PW Security and Backup version.
• The relevant administration screen.
• The exact error message.
• The operation performed before the problem occurred.
• Whether the issue continues after checking plugin or theme compatibility.
Never send WordPress passwords, additional security passwords, database credentials, private keys or complete backup archives in a public support request.
PW Security and Backup provides practical tools for monitoring, protecting and recovering WordPress websites. Careful configuration, regular review and verified external backups are essential for using these tools effectively.