MainWP Jetpack Scan - WordPress Plugin

MainWP Jetpack Scan Guide: Centralized Threat Scanning for WordPress Sites

MainWP Jetpack Scan is best viewed not as another security badge in the admin area, but as a workspace for someone responsible for multiple WordPress sites at once. This guide will help you build a clear workflow: prepare a dedicated MainWP dashboard, connect child sites, link them to Jetpack Scan, review findings in one place, and make a decision on each item without rushing to delete files.

The sections below cover more than interface options and buttons. You will learn what Jetpack Scan checks, why a clean threat report does not replace backups, how MainWP synchronization relates to the actual scan, when an automatic fix is appropriate, and when you should stop and move to logs, backups, or hosting support.

The practical section is based on a typical agency situation: after updates, you need to quickly identify which sites may be at risk, retain client context, and confirm that a fix actually worked. At the end, you will find a troubleshooting path for sites that do not sync, empty results, and threats for which the fix button is unavailable.

When Centralized Scanning Actually Makes Sense

You can open one site's admin area and inspect it manually. Once you manage five, fifteen, or several dozen sites, that habit creates blind spots. One client updated a site yesterday, another still has a vulnerable extension, and a third lost its connection to the security service after a hosting migration. The issue is no longer the lack of an individual scanner. It is the lack of one prioritized list. MainWP Jetpack Scan addresses that organizational problem: it shows connected child sites and provides a path from a summary to a specific threat.

The integration has two distinct roles. MainWP Dashboard is the central management panel, while Jetpack Scan performs the scan and reports its status. That leads to an important rule: MainWP is useful for viewing, sorting, and synchronizing results, but Jetpack Scan determines the source of a specific finding, its details, and the available remediation method. This distinction helps prevent you from confusing a data refresh with a new full site scan.

Who It Is For

The integration is especially useful for web agencies, freelancers offering maintenance packages, internal company teams managing several separate sites, and owners of networks of smaller projects. In all of these cases, teams need repeatable actions: spot a risk, assign an owner, document the decision, test the public-facing site, and retain a history. The approach also works well for mixed site portfolios where plugins and themes differ. The MainWP table lets you identify where the next review is needed without opening every individual admin area.

It is also useful for teams that want to reduce unnecessary staff accounts. An operator can begin from the central overview and receive access to a specific child site only when a particular case requires investigation. This does not replace the principle of least privilege, but it makes routine oversight more predictable.

When to Choose a Different Approach

There is little reason to install MainWP Jetpack Scan for a single site if you do not use MainWP for other management tasks. In that case, going through the standard Jetpack Scan page in the WordPress admin area is usually shorter. The integration also does not replace a backup system, uptime monitoring, an editor activity log, login protection, or permission management. Each layer has a different purpose, and expecting one scanner to handle everything creates a false sense of security.

The tool should not be chosen as an emergency cleanup method for a site that has already been heavily compromised. Jetpack's official documentation states that Scan is not intended to clean a site that was infected before the service was connected and for which there is no known clean state for comparison. In that situation, priorities should be isolation, contacting the hosting provider, using a verified backup, changing credentials, and conducting a professional investigation. Scanning is useful as an alert and an early-detection layer, not as a promise that every situation can be fixed automatically.

What the Workflow Consists Of

Before installation, it is important to name the components accurately. MainWP Dashboard is installed on a separate WordPress site used as the management panel. MainWP Child is installed on every site you want to manage. Jetpack, or a compatible method of connecting Jetpack Scan, must be configured on the child sites that will take part in scanning. Finally, the MainWP Jetpack Scan extension is added to the management site, not to every client installation.

This separation is not just a formality. If you place MainWP Dashboard on a public store or a regular corporate website, you mix a management workspace with a visitor-facing project and increase the likelihood of extension conflicts. MainWP documentation recommends a dedicated clean installation for Dashboard. It is easier to restrict access there, enable two-factor protection for administrators, and keep the number of additional plugins to a minimum.

What Is Included in a Scan and What Is Not

Jetpack Scan reports on files in the plugins, mu-plugins, themes, and uploads directories, as well as selected WordPress root files such as wp-config.php and parts of wp-content. This explains why results may include a known extension vulnerability, a suspicious file change, or an item that requires further review.

At the same time, remember an important boundary: Jetpack Scan does not scan the site's database. Therefore, the absence of threats in this panel does not prove that the database contains no spam records, unauthorized users, malicious links in content, or modified settings. The database requires a separate procedure: a backup, account review, publication audit, and, when necessary, consultation with an incident-response specialist. This limitation is especially important for online stores, where some business data lives in the database itself.

Five States You Should Not Confuse

How to read statuses while working with MainWP Jetpack Scan

Status	What It Means	Correct Next Step
Site connected to MainWP	MainWP Dashboard can communicate with MainWP Child.	Separately confirm that Jetpack Scan is connected and visible in the extension.
Site connected to Jetpack Scan	The scanning service recognizes the site and can return a status.	Open the MainWP overview and synchronize data if the entry does not appear.
Scan started	The scan request was accepted, but the output may not yet be final.	Do not draw conclusions from an old table until the status is refreshed.
Threat found	There is a specific item that must be read in full.	Identify the affected item, confirm backup availability, and review the available fix method.
Threat fixed or ignored	The action has been recorded in history, but this is not the same as a full site audit.	Test the site and document why that particular decision was made.

This table may seem obvious, but it protects against a common mistake: seeing a green MainWP connection status and assuming that every child site has already completed a successful Jetpack Scan. Dashboard-to-site connectivity, subscription availability, a completed scan, and the absence of active threats are separate facts that must be verified independently.

Prepare Before Connecting: Access, Backups, and Site Connectivity

Start with an inventory rather than uploading the extension archive. Make a list of sites, owners, responsible contacts, hosting providers, backup methods, business roles, and periods when technical work is acceptable. For an online store, even a routine update to a vulnerable extension is better scheduled outside peak ordering hours. For a campaign landing page, protecting the form from disruption matters most. A corporate portal may require approval from the IT team. Without this list, an operator sees only technical entries and can easily make a decision without the right context.

Set Up a Secure MainWP Dashboard

Install MainWP Dashboard on a dedicated WordPress site and do not use it as a public storefront. Create individual employee accounts, remove shared passwords, grant access only to people who need it, and configure reliable backups for the management panel itself. A separate dashboard does not make management completely safe, but it reduces the number of plugins, editors, and public-facing activities that can affect the connection to child sites.

For every child site, verify that MainWP Child is installed, active, and currently connected to Dashboard. MainWP provides a connection test that shows whether Dashboard can reach a particular site. A successful HTTP 200 response is useful, but do not treat it as a Jetpack Scan test. It only confirms the basic connection between the two MainWP components.

Check Requirements on Child Sites

Every site you plan to include in Jetpack Scan should have administrator access, a working MainWP connection, and Jetpack configured according to Jetpack Scan requirements. The official MainWP integration page specifically notes the need for a Jetpack Scan subscription. Do not try to bypass this step or substitute a third-party key. Doing so makes it difficult to determine who owns the site and who receives notifications.

Check whether the hosting environment prevents writing to the temporary /jetpack-temp/ directory in the site root. According to Jetpack Scan documentation, the service creates a temporary helper file there during a scan and removes it when the scan finishes. If the server prevents file changes, scanning may not work as expected. Your hosting request should be precise: permission is needed for normal Jetpack Scan operation, not a broad weakening of permissions across the entire site directory.

Create a Recovery Point Before the First Active Action

Create and verify a backup before using remediation actions on real findings. What matters is not merely a backup-created label, but the answer to three questions: where it is stored, who can restore it, and how restoration is tested. In the event of a critical threat, this preparation lets you preserve evidence first, then update or replace the component, and roll back to a known working state if necessary.

Do not run bulk remediation simply because the option is available in the interface. First confirm that you have a recent backup, determine the impact of the affected plugin or theme, and schedule a maintenance window for a site with visitors or active orders.

Minimum Privileges and Credentials

MainWP requires valid administrative permissions on the management and child installations. Do not send passwords through tasks, comments, or reports. If Jetpack Scan requires server credentials for more reliable operation, provide them only through the service's intended secure mechanism and only after evaluating the need. Official documentation notes that scanning and available automatic fixes may work without server credentials when the relevant Jetpack Protect requirements are met, while SSH/SFTP/FTP can make operations faster and more reliable. This does not mean such access should be granted to every site without review.

It is more practical to begin with the smallest necessary set of permissions, document who owns the access, and regularly review who still needs it. If a site changes hosting providers or contractors, review its connections and technical accounts. Former server access is more dangerous than a missing automatic-fix button.

Installing the Extension and Testing the Connection

The overall sequence is straightforward, but it is best to perform it first on one pilot site. Confirm that MainWP Dashboard and MainWP Child are already working. Then add MainWP Jetpack Scan to the management site, activate it in the extensions list, and open Jetpack Scan from the extensions section. Only after that should you connect the first child site through the Add App screen. The pilot should not be your most critical site, but it should be representative of your portfolio. This lets you test the full workflow without putting a key store or portal at risk.

Step 1. Confirm That MainWP Is Working

On the dedicated management site, open Plugins, make sure MainWP Dashboard is active, then go to MainWP > Sites > Manage Sites. The pilot site should not display an unresolved connection-loss message. If the site has not yet been added, use MainWP > Sites > Add New, enter its URL, confirm that MainWP Child is active, and use the connection test before completing the process.

If MainWP Child uses a unique Security ID, enter it in the child site settings in Dashboard. Do not disable the security identifier simply for convenience. An error stating that an identifier is required means the two sides expect the same secret for the connection. It does not mean that the Jetpack Scan extension is broken.

Step 2. Activate MainWP Jetpack Scan on Dashboard

Install the extension on the MainWP Dashboard site using the standard WordPress method and enable it under MainWP > Extensions. Then open Jetpack Scan from the extensions list. The purpose of this first visit is not to launch a bulk scan. It is to become familiar with three working areas: adding a connection, reviewing connected sites, and viewing threats together with their decision history.

Immediately document in your team's internal procedure who may add API connections, who may click a threat-remediation action, and who confirms the final outcome for a client site. In a small team, these may all be the same person, but it is still useful to separate the roles over time: analyze first, act second, then verify. This reduces the chance that the same operator will accidentally validate their own incorrect assumption.

Step 3. Connect the Pilot Site Through Add App

Within Jetpack Scan, go to Add App and follow the service's on-screen instructions to create or link the Jetpack Scan API. There is no need to document purchase steps or payment details here. The administrator's task is to link existing Jetpack Scan access to the correct child site without confusing projects. Verify the domain, owner, and contact email before confirming the connection.

After completion, do not rely solely on a successful-addition message. Go to Overview, locate the pilot site, compare its address with your inventory, and only then use the synchronization action. According to the MainWP page, the Sync Jetpack Scan Data button sends scan information to Dashboard. This is an important transition: first you create a connection, then you request an up-to-date view of that connection.

Step 4. Confirm the Outcome at Two Levels

The first level is the pilot site's row in Overview: it should appear as connected to Jetpack Scan. The second is the ability to open threat details or see a normal status with no active threats. If you see only the site row without details, check synchronization and the actual Jetpack Scan status on the child site. A working setup is not merely an added connection. It is a repeatable path from a site in the overview to a clear scan status.

After the pilot succeeds, connect the remaining sites in small groups. It is more useful to group them by owner, environment, hosting provider, or criticality than by random order. Then, if a connection problem repeats, you can quickly identify the shared factor: one server, the same WAF rule, a common configuration pattern, or a shared provider.

A Map of the Screens: Add App, Overview, Threats, History, and Manage Apps

It is best to learn the MainWP Jetpack Scan interface as a route rather than a collection of tabs. Each area answers a different question: how to create a connection, which sites are visible, what needs a decision, which decisions have already been made, and where the connection list is stored. If you begin with Threats without confirming Add App and Overview, you may waste time reviewing an outdated table. If you look only at History, you can easily miss a new active threat.

Add App: Link Sites Without Mixing Up Projects

The Add App screen is used to add Jetpack Scan APIs that connect child sites to the extension. Before adding one, keep a prepared site record nearby: domain, internal name, client, owner, purpose, backup status, and notes about critical integrations. When an organization manages similar domains, such as a primary site and a staging copy, this prevents access from being linked to the wrong project.

After adding a connection, do not leave unclear or temporary entries in the list. If a test domain has been retired, remove the connection promptly or mark it in the inventory. Otherwise, the next operator may see an outdated row and spend time investigating a problem that no longer exists.

Overview: A Queue for Initial Review

Overview brings connected sites together and provides a consolidated view of results. Do not try to fix everything immediately. First group findings by business criticality and recurring component. One vulnerable plugin installed on ten sites requires a different response from a single suspicious file on one project. The first situation calls for a coordinated update-and-test campaign; the second calls for a local investigation.

The MainWP page describes the ability to run an on-demand scan for all connected sites and then synchronize the data through Sync Jetpack Scan Data. For everyday work, this means you can request fresh information in an urgent situation, but the response still needs a thoughtful action queue. Do not turn the button into a ritual clicked every morning without reviewing the findings.

Threats: A Place for Decisions, Not Automation

In Threats, a result expands into a specific issue. Clicking a number or entry opens details and remediation guidance. Read the component name, finding type, available action, and site context. If the issue is a known plugin vulnerability, determine whether an update exists and whether the component is critical to checkout, forms, or an external-system integration. If it is a suspicious file modification, preserve the information first and verify whether the change is expected on that specific site.

A quick-fix button is a service recommendation, not a substitute for impact assessment. Jetpack's official documentation mentions automatic fixes for most issues, but also notes cases where they are unavailable. MainWP reflects that distinction in the interface: the extension changelog specifically notes that unfixable threats display a disabled button instead of a remediation action. This is useful interface honesty. Treat a gray button as a signal to move to a manual procedure, not as an obstacle to bypass.

History: The Log That Turns an Action Into Evidence

The History tab stores records of fixed or ignored threats along with the action time. Use the history as a brief decision log: what was detected, why it was fixed or deferred, who tested the public-facing site, and whether a follow-up task is needed. Do not leave an ignored threat without a comment in your internal system. A month later, nobody will remember whether it was an acceptable exception, a false positive, or simply unfinished work.

An ignored item should not be treated as a removed risk. It changes its history status and may be revisited, but it does not fix the site. If a team temporarily ignores a finding because of compatibility, document an expiration date and the condition for revisiting it, such as a vendor update or a migration. No History entry replaces testing the working site.

Manage Apps: Review Your Connections

The Manage Apps section shows the added Jetpack Scan APIs. Return here when a client changes, a domain is migrated, a project is closed, or maintenance is transferred. Compare the connection list with your inventory and remove anything that should no longer be associated with your dashboard. Regular reviews reduce the risk that an old API remains available to a former contractor or forgotten test site.

What Happens from Starting a Scan to Recording It in History

MainWP Jetpack Scan has a specific and useful operational flow. It can be expressed this way: a child site is enabled for Jetpack Scan, the service analyzes supported parts of the site, returns a status and threat details, and the MainWP extension collects that information in Dashboard. A person then makes a decision, performs an available action, and verifies the outcome. This chain explains why MainWP may sometimes show old information: the child site's state, the scan result, and Dashboard's synchronized table are not updated by the same button.

Input: Files and Information About Installed Components

For Jetpack Scan, the starting material is the files and related indicators on a child site. The service checks the WordPress areas listed in its documentation and compares known risks with installed components. That is why an operator should see more than a generic threat message. They should see the item it relates to: core files, a theme, a plugin, a must-use plugin, or an uploaded file. The more precisely the item is identified, the easier it is to assess the impact of a fix.

Do not extend that statement beyond the evidence. File scanning is not the same as a complete audit of site behavior, user permissions, the database, and external services. For example, Jetpack Scan may identify a vulnerable extension, but it does not determine whether the new version is compatible with your payment plugin. That question must be tested on the site itself.

Processing: Daily Scans and On-Demand Runs

Jetpack states that scans run daily or can be started manually. That is a good baseline rhythm, but it is not a reason to wait until the next day after a critical update or suspicious event. If you have just updated a component with a known issue, it is more useful to start an on-demand scan, wait for the status to update, and confirm that MainWP received the current result.

At the same time, there is no need to run scans continuously in the hope of receiving a different answer. If the service continues to report a threat, the problem is usually not scan frequency. The fix may not have applied, the site may be using another copy of the component, caching or synchronization may be showing an earlier state, or the finding may require a manual procedure. A practical approach is to change one factor, document it, and verify the outcome instead of generating a stream of identical scans.

Output: Overview, Details, and History

After a result is received, MainWP helps you move from broad information to a specific issue. In Overview, you select a site; in Threats, you read the details; and in History, you confirm the disposition of the item. This sequence is especially valuable when the same plugin is used on many sites. First you can see where it is installed, then build a safe update order, and finally return to history to confirm that actions were not lost.

A green indicator alone is not enough for a sound conclusion. Establish a three-part verification rule for the team: the threat entry has disappeared from the active list or changed to the expected status, the affected public-facing function works, and the task log includes a date and an owner. The combination of status, functional testing, and an action record is what turns automation into a controlled process.

Why Synchronization Deserves Its Own Step

It is useful to treat Sync Jetpack Scan Data as a way to retrieve a summary in MainWP, not as a magical repair. If Jetpack Scan has finished on a child site but MainWP still displays an earlier row, synchronization is needed to bring the current view into the central panel. If the Jetpack connection itself is missing, synchronization cannot replace connecting through Add App. If MainWP Child is not responding, restore the Dashboard-to-site connection first.

This distinction should shape your internal wording. Instead of saying "the scan does not work," clarify the actual issue: "the site is not visible in MainWP," "Jetpack Scan is not connected," "data is not synchronizing," "the scan did not finish," or "the finding has no available automatic action." Each statement leads to a different verification step and saves support time.

Set Up a Daily Process: Not All Sites Are Equal

It does not make sense to search MainWP Jetpack Scan for universal "best settings" in the form of a checklist of boxes. Its value comes from how you configure the process: which sites to connect, which order to use when reviewing risks, who receives notifications, how often synchronization is checked, and where decisions are documented. Jetpack's technical fields remain the source of facts, while your responsibility to site owners determines the response rules.

Classify Sites by Impact First

Create tags in MainWP or use your own classification system. For example: "critical sales," "contact forms," "corporate," "staging," and "archived." Define the required response to an active threat for each category. A store with payments and customer accounts normally needs a fast assessment and a mandatory test order after an update. A brochure site may allow a calmer maintenance window, but it should still have an owner.

A tag does not increase security by itself. It makes business priority visible. If ten issues are found on Monday, the operator begins not with the first domain alphabetically, but with the resource where a failure would cause the greatest harm. That is the practical value of a central dashboard.

Define Rules for Three Types of Findings

The first type is a known vulnerability in an installed plugin or theme with a clear update available. The usual route is to create a fresh backup, review vendor notes, update during an acceptable window, test the relevant function, and refresh MainWP data. The second type is a modified or suspicious file. Do not delete it from memory: preserve the identifier, review recent work, compare it with a backup, and escalate for investigation if necessary. The third type is a message requiring clarification or one that may be an exception. Do not hide it indefinitely. Document a temporary decision, reason, owner, and review date.

This approach is much more useful than a general instruction to "respond to high risk." It tells people what to do manually and what evidence is required after an action. If an automatic method is available, it can save time, but it does not replace this route.

Notifications and On-Call Coverage

Jetpack reports detected threats through the admin area, email, and the WordPress.com dashboard, while MainWP provides the central overview. Do not configure these channels so that one event creates noise for ten people. Choose a queue owner, a backup assignee, and an escalation channel for serious cases. For a client, a short and clear update is usually enough: what was found, which site is affected, what has already been checked, and when the next status update will be provided.

Also define what counts as confirmed notification delivery. An email in a shared mailbox with no owner is not the same as an accepted task. If the team uses a ticketing system, create a task with a direct reference to the site, affected component, and expected post-fix test. Then the notification remains a signal, while the actual work happens in a transparent process.

Do Not Mix Scheduled Maintenance with Threat Response

Scheduled updates for all components reduce the number of known risks. But an active detected threat requires its own decision because you do not know in advance how it will affect the site, what remediation is available, or how critical the site is. Do not automatically postpone it until the next general maintenance window if the risk level and business context call for earlier action. Conversely, do not send an entire portfolio into bulk updates because of one entry without reviewing shared dependencies.

A sound practice is to review the MainWP Jetpack Scan summary after every scheduled update and identify sites that need another functional check. In this way, routine maintenance and security reinforce one another: an update changes code, scanning highlights known risks, and manual testing confirms that the business function still works.

Working with Threats: From a Table Entry to a Safe Decision

The riskiest moment is not installation, but the first active row in Threats. The desire to click a fix immediately is understandable, especially when many entries appear. However, a quality response begins with reading the details. Open the issue and record at least the site, domain, component, finding type, suggested action, discovery time, recent backup availability, site owner, and expected post-change test.

Reviewing a Known Component Vulnerability

If an entry concerns a known plugin or theme vulnerability, determine whether the component is actually in use and whether it has a supported fix. Review it in this order:

1. Open the threat details and identify the component without abbreviating its name.
2. Confirm the site and its role in your inventory so that you do not apply a staging procedure to a live store.
3. Verify that a recent backup exists and that you know how to restore it.
4. Assess which pages, forms, payments, or integrations depend on the component.
5. Perform the available fix or update during an approved maintenance window.
6. Test the specific user journey and synchronize the updated status.

The final step matters. For a form, test sending a submission and receiving the notification. For a store, review a product, add it to the cart, and complete a test checkout in a safe environment if your organization's procedure allows it. For a corporate site, open key pages and test the contact form. The generic statement "the site opens" is not enough because a vulnerable component may control a feature that is not visible on the home page.

When Automatic Remediation Is Available

Jetpack describes one-click automatic fixes for most issues, and the interface may offer actions such as Auto fix all or Fix threat. Use them to speed up a well-understood operation, not as an experiment across all sites at once. On the first site in a group, review exactly what changes, run a functional test, and only then apply the same approach to similar projects.

If the affected plugin has been customized locally, automatic file restoration may erase that customization. That is why a backup and an understanding of where modifications are stored are necessary before taking action. Proper WordPress architecture places modifications in a child theme, separate functionality plugin, or documented extension point rather than editing core files or someone else's plugin. That makes updating and restoring original files much safer.

When the Fix Button Is Disabled

An inactive button does not mean MainWP has failed. The extension changelog explicitly documents a case where Fix Threat is replaced by a disabled button when an action is unavailable. Reasons vary: the issue may not support automatic remediation, no known replacement may exist, or the service may require a different path. In this situation, do not try to delete a file blindly. Open the details, document the finding, assess backup freshness, review the changelog, contact the theme or plugin vendor, or consult an incident-response specialist.

It is often safer to temporarily disable the affected extension on a non-public copy of the site, test restoration from a clean source, and only then move the solution into production. If the feature is essential, agree on a maintenance window and fallback plan. The central goal is to remove the risk without losing orders, content, or administrator access.

How to Use Ignore Threat

The Ignore threat action is appropriate only as a documented exception. For example, your environment may contain a modified file that is part of a documented integration and has been reviewed by the responsible developer. Even then, document who confirmed that it is legitimate, which version or branch the decision is based on, and when the exception must be reviewed. Do not use ignoring as a way to shorten the table. It weakens the signal that will matter during a real incident.

Jetpack history stores fixed and ignored entries, which helps you revisit the decision. But useful history exists only when your internal task also retains the context. The external service knows the technical fact; your team must preserve the business reason.

Practical Example: Updating a Vulnerable Plugin Across Client Sites

Imagine an agency that maintains twenty-five sites. After synchronization, Overview shows several entries related to one extension on four sites. Two are standard service websites, one receives inquiries through a form, and the fourth is used for order checkout. The goal is not to clear the table in five minutes. It is to eliminate a known risk without breaking different user journeys.

Goal and Preparation

The goal is to confirm that all four sites have received a safe fix and that their key functions still work. Preparation begins by creating a task for each domain. Record the site type, owner, backup status, maintenance window, and test path in each task. For a service site, that may include the home page, contact page, and form submission. For a store, it includes the catalog, cart, checkout, and order email. One general note such as "update the plugin on four domains" is too broad for quality verification.

Then open the first entry in Threats, confirm that the component and nature of the finding match the others, and review the proposed path. If an update is available, choose the least critical of the four sites as the pilot. If it is not, move immediately to a manual plan rather than repeatedly clicking a disabled button.

Pilot Remediation

Before changing the pilot site, create a backup recovery point and note the time. Then apply the available fix. Do not immediately switch to the next domain. Open the public-facing site in a separate browser without an admin session, follow the test path, review server error logs if you have access, and return to MainWP for synchronization. If the status changes as expected and the key function works, document the results in the task.

If a page displays an error after the update, you have received valuable information before a mass rollout. Record the step, restore the verified state according to your procedure, stop further rollout, and compare versions or dependencies. The cause may not be the fix itself. A conflict often comes from an older theme, additional module, cache, or local customization. In any case, the pilot protected the remaining sites.

Applying the Fix to Similar Sites

After a successful pilot, group the two service sites if their hosting, theme, and key extension sets match. Apply the change one site at a time or in small controlled groups. Repeat the short test and synchronization after every action. Do not replace testing with the statement that "the first site was fine." Even the same plugin can work differently with another theme, caching setup, or form handler.

Leave the store for last, even if it is technically similar. Agree in advance on a safe way to place a test order and verify that the email, status change, and cart pages work. If a test order is not possible, define an alternative set of evidence beforehand, such as testing the payment method in a test environment and reviewing logs. The important point is that the evidence should match the actual business risk.

Final Documentation

Once all four sites pass their checks, open Overview and make sure the central panel does not show an outdated status. Then review History and save a reference to the outcome or a clear description in each task: affected component, chosen path, confirmed functions, verification time, and remaining notes. This is useful during the next update, a client audit, or a staff handoff.

A good outcome does not sound like "there are no threats." It sounds like this: an approved action was applied to every affected site, the current status was synchronized, and an important user journey was tested after the change.

How to Confirm That Security and the Site Still Work After Changes

Outcome verification should be planned before you click a fix. Otherwise, after seeing a green status, the team starts trying to decide what to test. Every site has a minimum path that reflects its purpose. For a brochure site, this means opening the home page and target pages; for a form, sending a submission and receiving a notification; for a store, testing a product, cart, and checkout; and for a restricted portal, signing in under a standard role and opening a critical section.

Three Independent Verification Points

The first point is Jetpack Scan: the active entry should disappear or receive the expected new status after processing is complete. The second is MainWP: after synchronization, Overview and Threats should show the current picture. The third is the site itself: the key user journey should work outside the admin area. If one level conflicts with the others, do not force the answer to fit. Document the discrepancy and investigate its cause.

For example, Jetpack may already show a processed threat while MainWP has not synchronized the information yet. Or MainWP may show a clean overview while a form fails after the update. The first situation requires data exchange; the second requires functional troubleshooting and possibly a rollback. Neither can be solved with the same button.

A Monitoring Window After Remediation

After a significant action, assign a short monitoring window during which someone watches the site and is available to respond. For a critical project, this may be the next business period with a review of error analytics, submissions, and orders. For a less critical site, a scheduled follow-up synchronization review may be enough. The format depends on your responsibility, but the principle is the same: do not close the task the moment a button is clicked.

Also confirm that access to Dashboard and the Child Site was not accidentally disrupted. If an update affected a security component or an external-service connection, open MainWP > Sites > Manage Sites again, confirm that the connection is active, and only then remove temporary flags from the work list.

What to Include in the Final Note

• The site name and affected component.
• The reason for the action: a known risk, suspicious file, or another confirmed signal.
• The backup recovery point and the person responsible for restoration.
• The action taken: update, available automatic fix, manual investigation, or approved exception.
• The specific user journey that was tested.
• The synchronization outcome in MainWP and whether further monitoring is needed.

These six lines take less time than repeating an investigation a month later. They also separate the actual outcome from assumptions: the team can see what was done and which test confirmed it.

Team Procedure: Turn Signals into Repeatable Actions

A technical extension provides the most value when it is built into a simple procedure. Remove the expectation that someone will "just notice" an important row. Every event should have an owner, a deadline for the first assessment, a minimum set of evidence, and an escalation rule. The procedure does not need to be a twenty-page bureaucratic document. For a small team, one table in a task system and a short note template are often enough.

Morning Review Without Automatic Actions

At the beginning of the workday, the responsible person opens Overview, reviews new or changed entries, and separates them into three queues. The first includes projects with sales, customer accounts, public forms, and critical integrations. The second contains the remaining active client sites. The third includes staging and archived installations. This is not an attempt to replace Jetpack's technical severity assessment. It is a way to determine the order of human attention.

Then create or update a task for every new row. The operator does not have to fix the issue immediately, but they must leave a trace: the site has been identified, the entry has been reviewed, the backup has been checked, and the next step has been selected. Even if the action is moved to a maintenance window, the status becomes clear to everyone involved. This step is especially important during on-call handoffs and vacation periods.

How to Align Severity with the Site Owner

A client does not need a screenshot containing ten technical rows with no conclusion. A calm message is more useful: a risk was detected in a specific component, the team is reviewing the available fix, a backup recovery point was created before the change, and a specific function will be tested afterward. If the risk requires suspending part of the service, explain the possible effect, maintenance start time, and fallback contact method.

Do not promise that the scanner guarantees complete security. A more accurate statement is: the service detected a signal, the team applied a verifiable procedure, and monitoring continues. This is more honest and technically precise than absolute claims that no report can prove.

Four Questions Before Automatic Remediation

Before using an available Fix threat or Auto fix all action, ask yourself: Is there a recent backup? Is the affected component understood? Has its role on the site been verified? Is the post-change test defined? If any answer is no, it is better to postpone the automatic action and complete the incident record. This small filter protects against a situation where an efficient button fixes a file but the team has no plan for a function that stops working.

For a group of similar sites, add a fifth question: has a successful pilot been completed on the least critical project? If not, a bulk operation turns one unknown into several simultaneous unknowns. If yes, the team has a real testing approach and observable signs of success.

Weekly History Review

Once a week, review History not as a reporting checkbox, but to identify patterns. Repeated ignored entries may mean that a safe exception needs review. Frequent connection failures in one group of sites can point to hosting, DNS, SSL, or a WAF rule. Repeated vulnerabilities in one extension may require a decision about whether it remains an acceptable dependency. History becomes useful management information only when entries are compared over time.

It is useful to add one question to the review: "What manual action do we repeat regularly, and can we make it safer?" Sometimes the answer is not new automation, but a better test description, a clearer MainWP tag, or an updated owner list. Improvements like these reduce risk without increasing the number of plugins.

Connection Situations That Need Extra Attention

Sites rarely remain unchanged. They are moved between hosts, assigned new domains, given new SSL certificates, handed to clients, or restored after an error. These events matter for MainWP Jetpack Scan because they affect more than the public address. They affect the Dashboard-to-MainWP Child connection, Jetpack access, and the accuracy of the API connection list.

Migrating a Site to Another Host

After a migration, first check normal site operation, the SSL certificate, and DNS. Then run Test Connection in MainWP. If Dashboard sees an old IP address or receives an error, do not try to fix Jetpack Scan before restoring the basic connection. MainWP's official guidance specifically advises comparing IP addresses during DNS issues and contacting the hosting providers for DNS review or cache clearing when necessary.

Once the connection is restored, check MainWP Child, the Unique Security ID if used, and the current Jetpack Scan connection. Then synchronize the data and compare the domain with the inventory. A migration is a good time to remove old API entries and confirm that notifications reach the new responsible team.

Changing a Domain or Working with a Staging Copy

Confusing a live domain with a staging copy is particularly dangerous. They may have identical plugins and names but different roles, owners, and legal requirements for data. In Add App, verify the exact URL and do not use a site copy as the basis for decisions about the live site. Mark staging sites separately with a tag so their threats do not push real projects out of the queue.

If a clone is no longer needed, do not leave it as a forgotten connected object. Remove or revoke the connection according to the company process, review accounts, and exclude the domain from notifications. Old staging sites often become a source of unclear entries and unnecessary potential access points.

Restoring from a Backup

After restoration, a site may return to a state in which MainWP Child, Jetpack, certificates, or service connections differ from the current setup. Therefore, do not close an incident simply because the public page opens. Follow a checklist: sign in to the admin area, test the MainWP connection, confirm the needed Jetpack Scan connection, test a visitor path, synchronize the status, and record the backup recovery point used.

If the restoration is related to a threat, retain information about the original finding and its time. This helps distinguish new activity from an old record that has not yet refreshed. Do not assume that History alone will explain the entire cause-and-effect chain of the restoration.

Handing a Project Over to Another Contractor

When transferring a project, management boundaries matter as much as files. Clarify whether the site remains in your MainWP Dashboard, who owns Jetpack Scan access, whether the API connection must be removed, where notifications should go, and which backups have been transferred. Do not store credentials in a task note or send them through unsecured channels. A good handoff outcome is one where the site disappears from your active queue and the new operator receives a documented, secure path into their own management environment.

How to Combine Scanning, Updates, Backups, and Functional Testing

A resilient security process consists of several independent layers. MainWP Jetpack Scan signals known risks and scan states. Updates reduce the number of known vulnerabilities. Backups provide a way to recover. Access control reduces the chance of unauthorized entry. Functional testing shows whether the site still performs the purpose it exists for. Combining these layers into one "security status" is neither practical nor safe.

The Right Order Around an Update

Before an update: review the threat, create a backup, and define the test. During the update: apply one clear step and record the time. After the update: test the user journey, synchronize MainWP Jetpack Scan, and review history. This order is better than a random collection of actions because at every point you know exactly what changed and how to return to the previous state.

For a highly critical site, add an intermediate environment. Repeat the update on a copy first, test forms, payments, and integrations, then move to the live site during an agreed maintenance window. Even if Jetpack offers an automatic fix, a test environment remains valuable for dependencies the scanner does not know about.

Why a Scan Does Not Replace Backups

Scanning answers the question, "Is there a known signal that needs review?" A backup answers a different question: "Can we return the resource to a known state if a change goes wrong?" Automatic remediation without a backup leaves you without a reliable way back. A backup without a restoration test may be only a file that cannot be applied quickly. That is why these two points should exist separately in every risk record.

Using Jetpack Scan alongside backups can be helpful within the Jetpack ecosystem, but it does not remove the need to review your specific retention policy. Know the retention period, location and availability of copies, restoration process, and responsible person. Never publish server settings or backup archives in MainWP notes.

Why a Scan Does Not Replace Account Review

If a former contractor retains administrative access, the site remains at risk regardless of a clean threat table. After an incident, migration, or team change, review WordPress users, hosting accounts, domain access, external APIs, and notification mailboxes. Do this using a separate checklist based on the principle of least privilege.

This review is not directly part of the MainWP Jetpack Scan interface, but without it the guide would be incomplete. The integration can speed up detection of a technical signal, but it cannot replace management of people and access.

A Short Post-Change Verification Matrix

How to choose an outcome check by site type

Site Type	Minimum Test After the Fix	Additional Evidence
Service website	Open the home page and a target page, then submit the form.	Receive the notification and confirm that no new error appears in the log.
Online store	Review a product, use the cart, and check out using a safe procedure.	Order email, test order status, and payment-integration testing in an approved environment.
Restricted portal	Sign in under a standard role and open an important section.	Confirm access permissions and a key user action.
Staging environment	Reproduce the error or user journey for which the copy was created.	Compare behavior with production without transferring sensitive data.

This matrix does not replace a project test plan. Its purpose is to prevent a technical action from being completed without any observable outcome. For a complex integration, add specific steps rather than reducing the check to one home page.

Troubleshooting MainWP Jetpack Scan: Symptoms, Causes, and Safe Actions

Problems are easier to resolve when they are named accurately. The statement "the scanner does not work" can conceal a missing MainWP Child installation, a broken Dashboard-to-site connection, an incomplete Jetpack Scan connection, a hosting restriction, outdated MainWP data, or no available automatic fix. Begin with the screen where the symptom appears and change only one factor at a time.

The Site Does Not Appear in Overview

Symptom: the site appears in the general MainWP list, but after enabling the extension it is not listed among connected Jetpack Scan sites. Likely cause: Jetpack Scan has not yet been linked through Add App, Jetpack requirements have not been met on the child site, or the central dashboard has not yet received the data.

What to check: first open MainWP > Sites > Manage Sites and confirm that the basic Child Site connection works. Then, in Jetpack Scan, check whether a link was created in Add App and whether it appears in Manage Apps. After that, use Sync Jetpack Scan Data and compare the domain in the overview with the domain in your inventory.

How to fix it: restore the missing link in this order: MainWP Child, Dashboard connection, Jetpack Scan connection, synchronization. Do not remove the site from MainWP and reconnect it before checking the simple causes. Doing so may lose useful organization, tags, and internal work history. When to roll back: if a newly added API connection belongs to the wrong domain, it is safer to remove the incorrect link immediately and add it again using the site record.

Dashboard Reports That MainWP Child Is Missing or Not Responding

Symptom: a connection test, synchronization, or attempt to open the site produces a timeout, connection error, or a message that MainWP Child cannot be found. Likely cause: the Child plugin is inactive, requests are blocked by ModSecurity, Imunify360, Cloudflare, or another security layer, there is an SSL or DNS issue, or a security or caching plugin conflict exists.

What to check: use Test Connection, record the exact HTTP code or error text, and locate the Dashboard IP in MainWP > Status. MainWP documentation recommends comparing the block with server logs and WAF rules. If the SSL certificate is valid, do not disable its verification globally. If the certificate is self-signed or incorrectly configured, fix that on the server first. Temporarily disabling SSL verification for one specific site is appropriate only as a diagnostic action with a documented reason.

How to fix it: ask the hosting provider or WAF owner to allow expected Dashboard traffic for a specific reason and IP address rather than disabling protection entirely. To find a conflict, temporarily disable additional plugins one at a time during a test window while keeping MainWP Child active, and rerun the test after each change. When to roll back: re-enable temporarily disabled security plugins and rules immediately after diagnostics unless they were confirmed as the cause.

The Connection Requires a Unique Security ID

Symptom: Dashboard cannot connect to the child site and reports that a unique Security ID is required. Likely cause: an additional identifier check is enabled in MainWP Child, but the value was not entered or does not match on the Dashboard side. This is not a Jetpack Scan error.

What to check: on the child site, go to Settings > MainWP Child > Settings, locate the Unique Security ID field, and compare it with the setting for the corresponding site in MainWP > Sites > Manage Sites. For sites where Child settings are hidden by a white-label tool, official MainWP documentation describes locating the value in options.php under the mainwp_child_uniqueId key. Open this technical screen only with administrative access and do not copy its contents into messages.

How to fix it: enter the correct value in Dashboard, save the settings, and reconnect. When to roll back: do not disable Security ID simply because it adds an extra step. If the ID was replaced during a migration or restoration, document the new connection and confirm that the old value is not left in unsecured notes.

The Scan Does Not Finish or the Status Does Not Change for a Long Time

Symptom: you started a scan or are waiting for a scheduled result, but MainWP continues to display the previous state. Likely cause: data has not been synchronized yet, Jetpack Scan cannot operate normally with the file system, the server restricts creation of the helper file, or the issue is related to the Jetpack connection.

What to check: distinguish between manually starting a scan and using Sync Jetpack Scan Data. Then ask the hosting provider whether normal writes to /jetpack-temp/ are allowed, without exposing technical credentials to unrelated parties. Review Jetpack Scan status on the child site itself and compare the time of the last result with what MainWP displays.

How to fix it: remove the obstacle preventing normal Jetpack Scan operation, wait for completion, and synchronize again. If the issue appeared after migration, also check the domain, SSL, and DNS. When to roll back: if permissions or a WAF rule were temporarily changed for diagnostics, return them to the minimum required level after confirming operation. Do not leave the site directory with excessive write permissions for the sake of one scan.

Threats Contains a Finding but Fix Threat Is Unavailable

Symptom: you can see a threat, but the Fix threat action is inactive or missing. Likely cause: the service cannot automatically remediate that class of issue. This is an expected state that MainWP specifically accounted for in interface changes.

What to check: read the details, determine whether the entry concerns core files, a theme, a plugin, or an individual file, and confirm that a recent backup exists. Check vendor updates and consult the official documentation for the affected product. If there are signs of serious compromise, compare the site with a clean backup recovery point and involve the hosting provider or an incident-response specialist.

How to fix it: use the documented path: update to a fixed version, replace the item from a trusted source, disable an unused component, restore from a clean backup, or arrange professional cleanup. When to roll back: if an update breaks a key function, restore the verified state and do not mark the threat as resolved. Document a temporary risk limitation, define the next path, and continue the investigation.

MainWP Still Shows the Previous Threat After a Fix

Symptom: an update or available remediation was performed, but the row remains active in the central panel. Likely cause: MainWP has not yet synchronized data, processing on the Jetpack side has not finished, the wrong instance of the component was fixed, or another copy remains in the file system.

What to check: confirm that the action completed without an error, that the child site's admin area shows the intended component state, and then run Sync Jetpack Scan Data. Compare the object name and path in the threat details with what you updated. Then perform a functional test of the site.

How to fix it: wait for the status to update correctly. If the mismatch remains, refer to the exact Jetpack Scan message and create a task containing the facts. When to roll back: do not delete the entry manually or mark it as ignored simply to clean up the table. A rollback is for an unsuccessful site change, not for removing an inconvenient status.

A Form, Cart, or Other Function Stops Working After an Update

Symptom: the active threat disappears, but a public-facing site path produces an error, blank page, incorrect email, or cart failure. Likely cause: the updated component is incompatible with the theme, another plugin, a custom modification, or caching. The scanner cannot validate all of your site's business behavior.

What to check: repeat the predefined public-facing test, review browser console output and server logs through the responsible technical team, clear cache only if you understand its impact, and compare the error time with the action time. On a staging copy, isolate conflicts one component at a time. Do not experiment on a live store without a fallback plan.

How to fix it: apply a compatibility update from the vendor, adjust your custom modification in a child theme or separate functionality plugin, or restore a verified copy and schedule further work. When to roll back: if a critical function is broken and no quick safe fix is available, rolling back to a verified recovery point is preferable to lengthy troubleshooting on a public site.

A Short MainWP Interface Demonstration

The official MainWP video is useful for getting oriented within the extension interface. It specifically covers Jetpack Scan Extension and shows the purpose of the integration and a view of its interface. The video does not replace the procedure in this guide. After watching it, still compare labels and available actions with your current dashboard because the service interface may change.

In the first half-minute, the video explains that the extension lets you start vulnerability scans from MainWP Dashboard. After that, pay attention to the transition to the overview and the way an operator moves from the central list to the details. This supports the intent of learning how to use MainWP Jetpack Scan, but a safe decision about a detected threat still requires a backup and functional testing.

Questions That Come Up Before Connecting and After the First Threat

Do I Need Jetpack on Every Child Site?

For MainWP Jetpack Scan, Jetpack's official material indicates that the Jetpack plugin is required on MainWP sites. In practice, this means you must first make sure the setup works on the specific child site and only then expect it to appear in the integration overview. Do not stop at confirming that Jetpack is installed. Verify the actual Jetpack Scan connection and synchronization result.

Can I Use MainWP Jetpack Scan Without MainWP Child?

No. MainWP's central architecture is based on Dashboard and MainWP Child for managed sites. Jetpack Scan can be used on its own in its native environment, but the purpose of the MainWP extension is specifically to display the statuses of connected child sites in one panel. Resolve a missing Child installation as a MainWP issue first, not as a scanner issue.

How Often Are Scans Performed?

Jetpack Scan indicates daily scans and the option to start one manually. A daily rhythm does not define a specific hour, does not remove the need to respond to urgent updates, and does not guarantee that MainWP has already received a new summary. After an important action, use deliberate synchronization and confirm the actual status.

Does the Service Scan the WordPress Database?

No. Jetpack Scan documentation specifically states that the database is not included in scanning. Therefore, a file-based threat scan does not replace an audit of users, content, order tables, or settings. If an incident involves the database, use a backup and a separate investigation plan.

Why Does the Entry Remain in the Table After a Fix?

First separate two questions: did the action finish in Jetpack Scan, and did MainWP synchronize the new information? Check the status on the affected site, use Sync Jetpack Scan Data, and compare the specific object in the entry with what you changed. Do not hide the entry until you understand the reason.

Can I Always Click Auto Fix All?

No. Jetpack offers available automatic fixes for most issues, but this does not remove the need to create a backup and test site functionality. A bulk action is appropriate only after you understand the findings, complete a pilot application, and agree on the impact on sites. Incompatible or unknown cases require a manual route.

Why Does a Threat Have No Available Fix?

Not every finding can be handled automatically. It may be a problem that cannot be fixed with one action, a case requiring an update from the vendor, restoration of clean files, or an investigation after serious compromise. A gray control is not an invitation to find a workaround. It is a signal to move to details, a backup recovery point, and a confirmed manual plan.

Is the Tool Suitable for a WordPress Multisite Network?

Jetpack Scan's general documentation states that Jetpack Scan itself does not support Multisite. Do not apply the standard workflow in this guide to such a network without separately verifying support and creating a test plan. If necessary, choose a tool that explicitly documents support for your architecture.

When to Make the Integration Part of Your Regular Process

MainWP Jetpack Scan is a strong choice if you already manage multiple sites through MainWP and want to see Jetpack Scan status in one operational environment. Its strength is not a promise to remove every risk automatically, but the chain of "connected site - understandable threat - controlled action - history - outcome verification." The more sites and participants are involved, the more valuable that discipline becomes.

Start with a pilot site, test the route from Add App to History, define tests for different project types, and only then connect the rest of the group. Once the procedure is clear, you can get the WordPress version and use the extension as part of regular maintenance rather than as an occasional emergency button.