MainWP Broken Links Checker - WordPress Plugin

Guide to MainWP Broken Links Checker: broken link monitoring, setup, and a safe evaluation process

MainWP Broken Links Checker is not a typical standalone plugin for a single site. It is an extension for MainWP Dashboard that was designed to serve as a central screen for checking broken links across connected WordPress sites. In this guide, we will look at how to approach a tool like this realistically: what it was meant to do, which dependencies you need to verify, how to test it safely in an existing MainWP setup, and why it is important to assess support status, security, and alternatives before installing it.

This article does not repeat the product's short description. Instead, you will find a practical workflow below: prepare the Dashboard, verify child sites, run synchronization, review the results, fix links, monitor repeat issues, and create an exit plan in case the extension brings more risk than value. That approach matters most for agencies and webmasters managing many sites who cannot afford to experiment on a live control panel without a fallback plan.

A separate focus is placed on the product's current status. Based on public sources, MainWP Broken Links Checker belongs to the retired add-ons category, and publicly documented security issues exist for the older version. For that reason, this article does not assume the extension is suitable for every live site. It is more accurate to treat it as a tool for cautious evaluation, for maintaining an older setup, or for migrating a link-checking process to a more current solution.

If you need a quick answer on whether this plugin is worth using, go straight to the sections on preparation, risks, and alternatives. If the extension is already installed on your MainWP panel, start with diagnostics: check the version, license status, whether Broken Link Checker is present on child sites, synchronization errors, user permissions, and the state of the Dashboard database.

What problem this extension solves in the MainWP ecosystem

The main idea behind MainWP Broken Links Checker is to collect broken link data not from a single site, but from a group of child sites already connected to MainWP Dashboard. MainWP itself manages sites through a dedicated Dashboard plugin and MainWP Child on each managed site. This extension adds another layer to that model: it expects the Broken Link Checker plugin to be running on the child sites, pulls that data during synchronization, and shows a summary in the central panel.

That changes the webmaster's workflow. Instead of logging into each site's admin area, finding the link report, and fixing URLs one by one, the administrator gets a unified list of issues. In the extension's original workflow, you could see broken, redirected, dismissed, and all links in the reporting structure, and MainWP Client Reports included separate tokens for those values. For an agency, that is useful because broken links can become part of the regular maintenance process, allowing you to show clients not only plugin updates but also content quality.

At the same time, it is important to understand where the responsibility ends. This extension is not an independent crawler on the level of Screaming Frog, and it does not replace external SEO audits. It depends on the child site returning data correctly, on Broken Link Checker on that site actually scanning the content, and on the Dashboard being able to retrieve and store the results. If the scanner on the child site produces false positives, if the server blocks requests, or if the MainWP database does not record the URL table, the central screen will also be incomplete.

The main value of this product is a centralized triage dashboard for issues that have already been found, not a magical guarantee that every link on every site has been checked perfectly. That is why the setup described below is built around three layers: reliable data collection, safe link repair, and confirmation that the tool itself does not introduce a new risk to the Dashboard.

Which links and statuses usually matter most

When maintaining a network of sites, it helps to separate several types of results. A broken internal link usually disrupts navigation and should be fixed by replacing it with a new URL or adding a redirect. A broken external link may point to a deleted source, a removed document, expired partner content, or a page that has started returning an error. A redirect is not always a problem, but redirect chains are worth reviewing because they may end up on an irrelevant domain or weaken the user journey.

You should also look separately at images and files. If a link points to a missing PDF, media file, or old image, the user sees more than a simple 404 - they see a broken piece of an instruction, price list, portfolio, or documentation. On client sites, these issues often appear after a domain migration, a permalink structure change, deletion of older posts, content imports, or manual page edits in a builder.

Why centralized link checking is especially useful in MainWP

MainWP already knows the list of managed sites, can synchronize the status of child sites, shows updates, and lets you group sites by client or by tag. Link checking fits naturally into that model: first you choose a site group, then you get a summary, and after that you open a specific site or a specific post to fix the issue. The more sites you maintain, the more valuable a single shared screen becomes.

But that advantage only works when the process is disciplined. If the Dashboard has not been synchronized in a long time, if the child plugin is disabled, or if Broken Link Checker is not installed or is running in a different mode on part of the network, the summary will create a false sense of control. That is why link checking needs to be tied to the normal maintenance workflow: first backup and synchronization, then the report, then the fixes, then a follow-up check.

Who this approach is for and when another tool is the better choice

MainWP Broken Links Checker makes sense to consider if you already use MainWP, understand the Dashboard/Child architecture, and manage several WordPress sites as a single fleet. For one site, it is usually easier to install a current standalone scanner or use an external crawler. For a large agency, the extension could be useful precisely because it tied link issues to the maintenance panel already in use.

Good candidates for testing are older MainWP installations where the extension was already purchased, is still installed, and the team wants to understand whether it can still be used temporarily to inventory links before moving to another solution. The product can also be useful as a reference point for a developer studying older MainWP extension patterns and wanting to understand how child site data used to be passed into the Dashboard.

A bad scenario is installing it on a live Dashboard without checking the support status first. If the tool has officially been retired, no longer receives normal functional updates, and has public reports of unresolved security issues, it should not be enabled on a "let's install it and see" basis. You need to be especially careful on a Dashboard that has access to dozens of client sites, backups, reports, user accounts, and administrative actions.

If your only goal is to find broken links on one site, do not start with a retired MainWP extension. Use the current Broken Link Checker from WPMU DEV, an external crawler, or an SEO platform. If your goal is to monitor hundreds of sites centrally from MainWP, first evaluate an alternative process: regular exports from standalone scanners, scheduled external crawls, reporting in Ahrefs or Screaming Frog, or your own workflow built on current APIs.

The practical takeaway is simple: the product is interesting as part of an older MainWP workflow, but it should not be your first choice for a new installation if you need supported and secure link checking. In a new project, it is better to build the process around current tools and only consider this plugin after a deliberate assessment.

What to verify before installing or re-enabling it

Preparation matters more than the installation itself. This extension touches the central Dashboard, child sites, network requests, the database, and Broken Link Checker on the child sites. A failure at any layer can lead to empty reports, false results, server strain, or conflicts with the current MainWP version.

Check the status of the extension itself

Start by documenting where the file came from, which version is installed, whether there is an official source, and whether you are entitled to receive updates. The public MainWP repository lists version 4.0 and marks it as retired. On the MainWP retired add-ons page, the company explains that retired add-ons are no longer offered to new users and do not receive regular updates except in limited cases. That does not mean every older site is immediately broken, but it does mean you should not expect a normal support cycle.

If the file came from a questionable mirror, do not use it. This article does not list such sites and does not discuss ways to bypass licensing. For a production workflow, only verifiable sources are acceptable: your MainWP account, the official repository, or your own archive that you have used before and can validate. Even then, activation should start on a staging copy of the Dashboard.

Verify MainWP Dashboard and the child sites

The Dashboard must be installed and active on a dedicated WordPress site, and the child sites must be connected through MainWP Child. MainWP's official documentation states that add-ons are installed on the Dashboard site, not on the managed child sites. That is a common trap: if you install the extension on a child site, you will not get a central link-checking panel.

Before testing, run a manual synchronization on several sites and confirm that MainWP can see updates, plugin status, and basic site information. If connection issues already exist, fix those first. Broken link checking should not be used to paper over a fundamental communication problem between the Dashboard and the child sites.

Check Broken Link Checker on the child sites

The extension code points to the related plugin slug broken-link-checker/broken-link-checker.php. That means the extension historically relied on data from the Broken Link Checker plugin installed on the child sites. If that plugin is missing from a child site, or if it is running in a mode that does not expose the expected data, the central screen will be empty or incomplete.

There is a separate nuance with current Broken Link Checker versions: modern WPMU DEV documentation describes both cloud and local modes. The older MainWP extension was designed around an earlier integration model, so you should not confidently assume full compatibility with the newer cloud workflow. For testing, pick one site, enable local mode where it is available, wait for the report, and only then check whether MainWP Dashboard can see the data.

Prepare a fallback plan

Before enabling the extension, create a backup of the Dashboard site and at least one test child site. Record which plugins are active, what role the user has, and which MainWP extensions are enabled. If you have a staging copy of the Dashboard, use it first. If staging is not possible, limit the test to a few low-risk sites and do not run bulk link fixes until you have verified the results.

Minimum safe preparation: a Dashboard backup, a backup of the test child site, a fresh MainWP synchronization, admin permission verification, one test site, one manual report, and one rollback scenario.

Installation in broad terms and the first check after activation

Technically, installation is similar to any other MainWP add-on: the ZIP file is uploaded to the site where MainWP Dashboard is installed, then the plugin is activated in WordPress and appears in the MainWP extensions list. But because of the retired status and its dependency on child sites, the standard "upload and activate" instruction is not enough here. You need an initial validation step that confirms the extension did not just turn on, but actually integrated correctly with the Dashboard.

1. Open the Dashboard site, not one of the managed child sites.
2. Go to WP Admin > Plugins > Add New and upload the extension archive if you are testing a manual installation.
3. Activate the plugin and confirm that a section or extension card appears in MainWP.
4. Open MainWP > Add-ons > Manage Add-ons and make sure the extension does not show unexpected activation errors.
5. Select one child site where Broken Link Checker is already installed and has completed a scan.
6. Run synchronization for that child site from MainWP and check whether the link summary appears.

At this stage, do not fix links in bulk. The first goal is to verify three things: the extension can see MainWP, MainWP can see the child site, and the child site is returning link data. If any of those layers fails, bulk actions will only make diagnostics harder.

If activation triggers a redirect to the Extensions page, that is expected for the extension's older logic: the activation code sends the user to the extensions area. But the redirect itself does not prove that the license, tables, and data exchange are working. Check the PHP error log, the browser console, and the MainWP status screen. Older JavaScript dependencies and interface changes in MainWP may only become visible once you open the extension page.

What counts as a successful first check

A successful check looks like this: the Dashboard does not show critical PHP errors, the extension page opens, the test child site synchronizes, Broken Link Checker data appears in the summary, and opening the specific site does not trigger an access error. If you only see a general counter without a URL list, that is only a partial success. Community discussions have described a scenario where summary information appeared but the URL table was not populated. That result should not be treated as a working installation for real link repair.

After the first check, open the child site itself and compare the data. If Broken Link Checker on the child site shows 12 issues but MainWP displays 0 or a different number with no explanation, investigate synchronization first. It is normal for some links to be hidden as ignored or dismissed, but that should be clear from the report state rather than guessed.

When it is better to stop immediately

Stop the test if activating the extension breaks the MainWP page, triggers nonce errors, prevents admin URLs from opening, hides data from other extensions, or causes your security system to flag the installed version as vulnerable. For a link maintenance tool, the risk of losing control over the Dashboard is unacceptable. In that situation, the safer path is to disable the extension, clear the admin cache, review the logs, and move to an alternative link-checking process.

Post-install setup: synchronization, limits, and a workable rhythm

Detailed setup for MainWP Broken Links Checker does not begin with a polished interface. It begins with a simple question: how often do you want to collect data, and how much load are you willing to place on the child sites? Link checking can be resource-intensive, especially on sites with large post archives, old comments, media libraries, external links, and builder-based pages. If you run everything at once, you may end up with timeouts, false errors, or conflicts with the normal maintenance window.

First configure the data source on the child site

On the test child site, open Broken Link Checker and make sure it has already finished scanning. If you are using the modern WPMU DEV plugin, verify which mode is active - cloud or local. For an older integration, it is safer to start with local data where your version allows it, because the MainWP extension historically expected the plugin's local site data. If the site is connected to WPMU DEV Hub and relies only on a cloud report, do not assume compatibility has been proven until the Dashboard can see specific URLs.

Next, configure exclusions. Every link checker will generate false positives: temporary 403 responses from security services, YouTube links, marketplaces, external CDNs, Amazon, Cloudflare protection, or pages that return a nonstandard response to bots. If the child site marks those links as broken, MainWP will simply carry that noise upward. It is better to define ignore rules once at the source than to sort through hundreds of false rows in the central panel.

Mini-check of the source data

Take one known problematic link, verify that the child site can see it in its own report, then check whether the same link appears in MainWP after synchronization. If that test row does not make the full trip, it is too early to scale the setup.

Limit the scope of the first synchronization

Do not start with the "all sites" group. Choose one site with a straightforward structure, then one site with a moderate amount of content, then one problematic site. After each step, compare the report on the child site with what appears in MainWP. If the data matches, expand the sample. If timeouts or empty URL lists start to appear, reduce the scope and check the logs.

The old extension changelog mentioned an option to limit the number of links returned from child sites. That is an important idea even if your interface does not expose it exactly the same way: large networks do not need everything pulled in at once. Start with a limited set, fix the most visible 404s and redirects, then run a follow-up check.

Define a working review cadence

A weekly or monthly cycle is often practical for an agency, but the right frequency depends on the type of sites you manage. A news site, a blog with many external links, and a document archive all need more frequent checking than a static brochure site. An online store with many products and external files should be checked after large imports, migrations, and permalink changes.

Do not tie link checking to the same moment as bulk plugin and theme updates. If something breaks after an update and a heavy link scan is running at the same time, diagnosis becomes harder. A better rhythm is: backup, updates, availability checks, then a separate window for links and content.

Set up roles and access

MainWP Dashboard is often used by several people: the agency owner, a technical specialist, a content manager, and an account manager. Not all of them should have access to fix links. A user who only prepares a report may need to see the number of broken links, but should not be changing URLs in production without review. If MainWP team features are enabled, confirm that the user has permissions for the required extension and sites. Community discussions have described cases where permissions and nonce checks caused access errors after Dashboard updates.

With an older extension, it is safer to keep control in the hands of an administrator and give the content team an export or a task list with specific URLs. That reduces the risk of accidental bulk edits, especially when you are dealing with client sites that follow different editorial rules.

How to roll back a questionable setting

If empty reports start appearing after changing limits, enabling a new Broken Link Checker mode, or updating MainWP, return to the last working state: disable the extension, check the child site on its own, clear the browser and admin cache, and resynchronize one site. Do not immediately delete all data if you still need it for comparison. First record the symptom: an empty list, a nonce error, a PHP warning, an incorrect counter, or a mismatch between the Dashboard and the child site.

How to read the report: broken, redirected, dismissed, and all links

A link summary is only useful when the team interprets the statuses the same way. In older MainWP Client Reports tokens for Broken Links Checker, there were separate values for broken, redirect, dismissed, and all. That is a good framework for reviewing results even if the interface in your installation looks different.

Broken means the tool considers the link non-working. The reason may be a real 404 page, a timeout, a DNS issue, bot blocking, or an access error. Redirect means the link does not lead directly to the final URL, but goes through a redirect. Dismissed means the user chose not to fix the issue or temporarily hid it. All links is the total volume of links checked, which helps you understand the scale of the scan.

The most common mistake is to fix everything marked broken without checking manually. For internal links, that is often acceptable, but for external sources it is better to open the URL in a browser, verify the response code, and understand the context. Some sites block automated requests but open normally for real users. Others return 403 because of geography, Cloudflare, rate limits, or bot protection. If you remove such a link without checking, you may end up deleting a useful source.

Fixing priorities

Start with links that affect the user journey and trust in the page. That means menus, buttons, document download links, service pages, instructions, contact pages, older high-traffic content, and internal links from cornerstone content. Then move on to external sources in articles, comments, and archive materials. Leave dismissed items and ambiguous redirects for the end, where the content owner may need to make the final call.

• Fix an internal 404 in a menu or an important article right away: replace the URL, restore the page, or set up a redirect.
• Review an external 404 in an older article manually: you may need a new source, an archived copy, or complete removal of the link.
• Analyze a redirect to a new domain carefully: if the final domain is no longer relevant, it is better to replace the link.
• Check image-related errors directly on the page: the user may see a blank block even if the article text itself still reads fine.

How not to lose the context behind a fix

A link by itself does not always tell you what needs to be done. You need to know the source page, the anchor text, the content type, and the role the link plays. If MainWP shows only the URL without enough context, open the child site and the original post. The fix should preserve the meaning of the paragraph. If the link pointed to documentation, replace it with current documentation, not the site's home page. If it pointed to a file, determine whether the file itself is still needed or whether removing the mention is enough.

For client work, a simple log is useful: site, page, old URL, new action, who reviewed it, and whether follow-up verification is needed. That does not have to happen inside the extension. The important thing is not to turn a broken-link list into a chaotic set of manual edits with no history behind them.

Practical scenario: auditing links across a group of client sites

Consider a real-world task: an agency manages several WordPress sites after a migration to new domains and wants to check whether old URLs still remain in articles, buttons, documents, and media. MainWP is already being used for updates, so it makes sense to start with the central panel. The goal is to produce a verifiable list of issues, fix critical links, and show the client that the outcome was checked again afterward.

Goal

You need to find internal links to the old domain, external 404s in popular articles, and missing PDF files. After the fixes, the client should receive a short report: how many links were checked, how many issues were found, what was fixed, what remains unresolved, and when the next review is needed.

Preparation

Create a backup of the Dashboard. On the child sites, make sure MainWP Child is connected and Broken Link Checker has finished scanning. For the first pass, choose 2-3 sites, not the entire network. If one site has a very large archive, leave it for the second pass so you can first confirm that the integration works.

Steps

1. Open MainWP Dashboard and run a sync for the selected child sites.
2. Go to the extension screen and sort the results by site or by status.
3. Start with internal broken links that point to the old domain or to missing pages.
4. For each link, open the source page on the child site and review the context.
5. Replace the URL with the current one, restore the page, or configure a redirect using the site's standard tools.
6. For external links, verify the final URL manually, then replace the source or mark the issue for later review.
7. After each batch of fixes, run a new scan on the child site and then resync in MainWP.
8. Compare the number of broken links before and after, then record the result in the report.

Verifying the result

A successful result is visible on two levels. On the child site, Broken Link Checker no longer marks the fixed URLs as broken. In MainWP, the issue count for that site drops after sync. In addition, open 3-5 corrected pages as a normal visitor, especially if the links appear in buttons, menus, builder blocks, or documents.

Do not treat the task as finished until you have checked the source page itself, not just the row in the report. A link checker confirms the technical response, but it does not always understand the editorial meaning of a replacement.

A nuance that often gets in the way

After a link is fixed, the report may not update immediately. The reason may be result caching, a delayed scan task on the child site, or the fact that MainWP has not yet synchronized extension-specific data. In that situation, do not fix the same link again. First refresh the scan on the child site, then run sync in the Dashboard, and only then review the row again.

Practical use cases for agencies and editorial teams

Link checking becomes more useful when it is tied to specific roles. The same broken-link list is interpreted differently by a technical specialist, an editor, and a client services manager. MainWP Broken Links Checker has historical value precisely because it gathers data in one central place, making it a good starting point for several workflows.

For the technical specialist

The technical specialist uses the extension as an early warning signal. If the number of broken links suddenly jumps across several sites after a migration, a URL structure change, or an import, that is a reason to check permalinks, redirects, the CDN, the media library, and cache rules. Here, not only the list of URLs matters, but also the pattern of the issues: the same old domain appearing across dozens of posts points to a systemic migration mistake.

For this role, verification means running another scan and doing a spot-check crawl with an external tool. If MainWP shows that the issues are gone but Screaming Frog still finds 404s on public pages, you need to determine where the data sources diverge: cache, robots rules, JavaScript links, blocked pages, or a different user agent.

For the content editor

The editor does not need to see every technical detail of the Dashboard. What they need is a list of pages where a link has lost its meaning. For example, an old article may link to documentation that has been removed, or a product review may contain a demo link that no longer works. The editor decides whether to replace the source, rewrite the section, remove the outdated paragraph, or add a current explanation.

In this scenario, it is important not to give the editor a bulk-fix button. It is better to pass along a task with context: the page, the anchor text, the old URL, and the recommended action. That way, fixes do not turn into mechanical deletion of useful links.

For the client report

If the agency sends maintenance reports on a regular basis, broken-link data can be turned into a clear result: found, fixed, and pending approval. Older MainWP Client Reports supported tokens for broken, redirect, dismissed, and all links, so the reporting concept itself fits well with MainWP. Even if you no longer use this extension, the structure of that report remains useful.

The report should not overwhelm the client with technical rows. Show the outcome instead: critical internal links were fixed, questionable external sources were passed to the editor, redirects were reviewed, and the next scan has been scheduled. That frames link checking as part of site quality, not as random technical busywork.

Verifying the result on the site and in the admin panel

After making fixes, it is important to prove that the system works. MainWP Broken Links Checker gives you two layers of results: the data in the Dashboard and the actual page behavior seen by visitors. If only the first layer matches, you have a clean-looking report but no confidence in the user experience. If you only check the page manually, you do not know whether the central summary has been updated.

Start with one specific link. Take one row from the report, open the source page, fix the URL, save the post, clear the page cache, open the link in a private window, and check the response code. Then go back to the child site, rerun the scan, and confirm that the issue is gone. After that, perform a sync in MainWP and see whether the counter changed.

If the result does not change, break the verification down into three questions. First: does Broken Link Checker on the child site still see the issue? Second: did MainWP update the extension-specific sync data? Third: is an old page cache hiding the fact that the link was already fixed? That kind of review is faster than changing settings at random.

Checklist after the first successful fix

• The fixed link opens for a normal visitor without logging into the admin panel.
• The source page no longer contains the old URL in the HTML, button, builder block, or custom field.
• Broken Link Checker on the child site no longer marks that link as broken.
• MainWP Dashboard shows fewer issues or an updated status after synchronization.
• If the link was external, the editor confirmed that the new source preserves the meaning of the material.

For important pages, add an external crawl. That is especially useful after migrations and bulk URL replacements. An internal plugin may miss some JavaScript links or pages that are blocked from scanning, while an external crawler will show the public-facing picture.

Limitations, security, and the decision on whether to keep using it

This section should not be skipped. MainWP Broken Links Checker is tied to a central site management panel, not to an isolated function on a single blog. That makes security more important than convenience. Public sources indicate that the extension has been retired from the active MainWP lineup, and vulnerability databases point to issues in version 4.0 without a normal patched release. That is not a minor technical detail - it is a decision-making factor.

Do not install or keep the extension on a production Dashboard just for the convenience of a clean report if you cannot accept and control the risk. At a minimum, you need Dashboard isolation, strict roles, an up-to-date WordPress core, limited admin access, backups, activity logs, file verification, and a removal plan. For most new installations, a supported tool is the more sensible choice.

Compatibility is another major limitation. The modern Broken Link Checker from WPMU DEV changed its operating model, including a cloud engine and Hub-based workflows. The older MainWP extension may not understand that data the same way it handled the earlier local table. If you only see part of the results or an empty URL table, do not conclude that the site is clean. Run a validation crawl with another tool.

Finally, there is an operational limitation: broken links are not always the plugin's fault or the site's fault. Some external resources block automated checks, some links are temporarily unavailable, and some redirects are acceptable. Good configuration is not about forcing the counter to zero at any cost. It is about separating real issues from noise.

Safe improvements without editing the extension code

For this product, you should not add a PHP snippet or edit extension files as a "quick fix." No reliable current extension points for custom code were found for this retired product, and editing old Dashboard code can create a new risk. Instead, use safe operational improvements:

• Keep the extension disabled until you need a specific test on staging.
• Restrict Dashboard access to administrators responsible for maintenance.
• Fix links using standard WordPress tools on the child site, not by editing the database directly.
• For bulk replacements, use trusted search/replace tools only after a backup and on a limited sample.
• Keep a separate fix log for reporting so you do not depend on the old extension interface.

If you still need a code-level fix, treat it as maintaining your own fork: a separate repository, code review, a test copy of the Dashboard, a security audit, and a clear maintenance plan. For a typical webmaster, that is too high a price to pay just to check links.

Diagnosing common issues and choosing safe fixes

Problems with this kind of extension often look similar: the page opens, but the data does not match, the URL list is empty, some buttons do not work, or MainWP shows an access error. To avoid fixing things blindly, break the symptom down by layer: Dashboard, extension, child site, Broken Link Checker, network, cache, and user permissions.

The extension is enabled, but MainWP shows no link data

Symptom: the extension page opens, but the link list is empty or shows zeros. Possible cause: Broken Link Checker is missing from the child site, the scan has not finished yet, MainWP did not synchronize extension-specific data, or the new data source version is not compatible with the old integration.

Check the child site directly. If there is no link report there, MainWP has nothing to pull. If the report exists, sync the selected site in the Dashboard and review the logs. If the summary appears but the URL list stays empty, do not treat that as a working mode: users have discussed this symptom as a problem with storing URL data.

Fix: start with one site, local mode where it is available, and a fresh synchronization. If the data still does not come through, disable the extension and use an alternative scanner. Do not run bulk fixes based on an incomplete report.

You see an Unauthorized request error or a nonce message

Symptom: after Dashboard updates or when following admin links, you see a message about an invalid or missing nonce. Possible cause: the older extension does not match MainWP's newer requirements for transition verification and permission checks. Community discussions mentioned a case where MainWP added nonce verification for Go to WP Admin, and third-party extensions needed to adapt.

Check whether the problem happens only with MainWP Broken Links Checker. Clear the browser cache, do a hard refresh, verify the user role, and temporarily disable the extension. If the error disappears after the extension is disabled, do not leave it enabled on a live Dashboard without a patched fork.

Fix: for a normal user, the safe path is to disable the extension and switch to a supported process. Manually editing nonce-related code inside the old extension is only appropriate for a developer who is prepared to maintain the fork and review its security.

Too many false broken links

Symptom: the report shows many external errors, but some of those URLs open in a browser. Possible cause: the external service blocks automated requests, uses protective filtering, expects a different user agent, or temporarily returns a nonstandard code. Discussions around this class of tools often mention YouTube, Cloudflare, Amazon, and similar platforms.

Check several URLs manually and with an external crawler. If the issue only repeats in one link checker, configure ignore rules on the child site or mark those links for later review. Do not remove such links in bulk. For important pages, replace the source only after editorial review.

Fix: reduce the noise at the data source level, not in MainWP. The central panel should receive a cleaned-up list, otherwise it stops helping with prioritization.

The link stays in the report after it was fixed

Symptom: the link was replaced on the page, but the Dashboard still shows it as broken. Possible cause: an old scan cache on the child site, no follow-up sync, page caching, or the link still exists in a custom field or builder block.

Check the public HTML of the page and search for the old URL inside the admin area. Then rerun the scan on the child site and resynchronize MainWP. If the URL disappears on the child site but remains in the Dashboard, the problem is in data transfer or the extension's tables.

Fix: do not change the link a second time. Wait for a new scan, clear the cache, and run sync. If the issue persists only in MainWP, record it in your log and treat the child-site report as the source of truth.

When to roll back the fix

Rollback is necessary if the new link opens technically, but leads to an irrelevant source, changes the meaning of the instruction, or breaks a button on the public site. In that case, restore the original text context, find a more accurate source, and verify the result again.

The Dashboard starts running more slowly

Symptom: after enabling link checking, MainWP opens pages slowly or sync takes noticeably longer. Possible cause: a large amount of URL data, a heavy child-site scan, weak hosting limits, or a conflict with other maintenance tasks.

Check Dashboard load, table size, PHP execution time, and the schedule of other jobs. Do not run link checking at the same time as updates, backups, and bulk imports. For large networks, split sites into groups.

Fix: reduce the scope, disable the extension after a one-time audit, or move link checking to an external tool. If the Dashboard is a critical control panel, its stability matters more than the convenience of a single report.

When MainWP Broken Links Checker can still be a good fit

MainWP Broken Links Checker can still be useful as a temporary tool for owners of older MainWP installations who need to understand link health before migrating the process. It also helps illustrate what centralized link monitoring should look like in an agency workflow: one Dashboard, many child sites, broken/redirected/dismissed statuses, a client report, and follow-up verification.

But for a new installation, the decision should start with risk. If you need safe, ongoing link monitoring, choose a supported plugin, an external crawl, or an SEO platform. If you already have an archived copy and want to evaluate it on a Dashboard clone, use this guide as your checklist: backup, staging, one child site, local data, sync, result verification, diagnostics, then a replacement decision.

Before you get the WordPress version, make sure you understand its retired status, its dependency on Broken Link Checker on child sites, and its security limitations. A good test outcome does not necessarily mean leaving the extension enabled. Sometimes the right decision is to get the list of issues, close the critical links, and move to a more current tool.

If the product remains part of your workflow, keep it tightly controlled: limited access, regular backups, manual review of questionable URLs, an external crawl for important pages, and a clear retirement plan. That way, broken-link monitoring supports site maintenance instead of becoming an additional risk for the central MainWP panel.