This article explains the decisions behind the tool, how its audit workflow is organized, and why an automated result should be treated as evidence to review rather than an instruction to delete a link.

The maintenance problem I wanted to solve

A single article may contain only a handful of links, but a publication with hundreds of pages can contain thousands of internal and external destinations. Over time:

• Pages are deleted or renamed.

• Permalink structures change.

• External documentation moves.

• Domains expire.

• Temporary server failures appear.

• Security systems block automated requests.

Opening every page and testing every link manually does not scale. I wanted a tool that could automate discovery and status checking while keeping the final decision with the website owner.

The resulting PAH Broken Link Checker can audit up to 500 eligible public pages and organize the detected links into useful status groups.

Start with the website, not a random page

The tool expects a website homepage as its starting point. From there, it looks for a public XML sitemap and collects eligible same-domain page URLs.

This approach has two practical benefits:

1. It gives the audit a defined scope.

2. It avoids blindly crawling every URL that can be reached through navigation, calendars, filters, or other potentially unlimited paths.

Sitemaps are not perfect inventories, but they are usually a sensible starting point for a repeatable website audit.

Separate page discovery from link checking

The workflow has two distinct stages.

First, the checker discovers and retrieves eligible website pages. It then extracts standard HTTP or HTTPS links from their HTML.

Second, it deduplicates destination URLs and checks their responses. Deduplication matters because the same navigation, footer, legal, or reference link may appear across many pages. Checking identical destinations repeatedly would slow the audit and make the final report harder to review.

The report also keeps a discovered source page for each destination. A broken URL without context is less useful than a broken URL accompanied by a page where it was found.

A non-200 response is not always broken

One of the most important design decisions was to avoid treating every non-200 response as the same problem.

Successful responses

A 2xx response generally means the destination was reachable during the scan. It does not guarantee that the content is still relevant, but it normally requires no immediate technical correction.

Redirects

Responses such as 301, 302, 307, and 308 are shown separately. Redirects are normal when pages move, so they are not automatically classified as broken.

For an important internal link, it may still be worth updating the source to point directly to the final destination. That reduces unnecessary redirect hops and keeps the website's internal references current.

Restricted responses

The checker separates 401, 403, and 429 responses into a restricted category.

These codes can appear because a destination requires authentication, blocks automated traffic, applies firewall rules, or rate-limits repeated requests. A normal browser may still be able to open the page, so deleting the link automatically would be the wrong response.

Broken responses

Responses such as 404 and 410 usually indicate that the resource is unavailable at the requested address. Other 4xx or 5xx results may also require investigation, depending on their meaning and whether the failure persists.

Request errors

Timeouts, DNS failures, and refused connections do not always prove that a page is permanently unavailable. They are reported separately so the user can retry or verify the destination from another network.

Why manual verification still matters

Automated link checkers interact with websites differently from human visitors. Bot protection, JavaScript rendering, authentication, regional restrictions, and temporary outages can all affect a result.

My preferred workflow is:

1. Filter the audit to broken or uncertain results.

2. Open the reported source page to understand the link's purpose.

3. Test the destination in a normal browser.

4. Confirm whether the failure is permanent.

5. Correct, replace, redirect, or remove the link based on context.

6. Run the audit again after making changes.

This avoids turning a useful diagnostic tool into an automatic content-deletion system.

Choosing the right fix

Different failures require different actions.

A redirect should lead to a genuinely relevant replacement. Sending every missing page to the homepage may hide the error without helping the visitor.

Building it for WordPress

The published implementation is written in PHP and designed for WordPress. It can be integrated through the included shortcode:

[pah_broken_link_checker]

The interface provides status filters, report search, source-page information, and CSV export so results can be reviewed in Excel or Google Sheets.

The source implementation is publicly available in the PAH Broken Link Checker GitHub repository. The repository also includes contribution guidance, a security policy, issue templates, and notes about responsible reporting.

The code is source-available for review and improvement. No open-source license is granted unless a license file explicitly says otherwise, so users should review the repository's ownership terms before reuse.

Limitations worth documenting

Clear limitations make an auditing tool more trustworthy.

• The current scan is limited to 500 eligible pages.

• Page discovery depends on a readable public sitemap.

• The scanner extracts standard anchor links present in retrieved HTML.

• Links created only after complex JavaScript execution may be missed.

• Some destinations intentionally block automated requests.

• The stored source page is a discovered occurrence, not a complete backlink report.

• A successful HTTP response cannot determine whether the page's content is accurate or relevant.

These limitations do not make the audit useless. They define what the results can reliably tell you.

Final takeaway

A broken-link audit works best when automation and human judgment are combined. Automation can discover pages, collect destinations, test responses, remove repetition, and highlight likely problems. A person still needs to understand why the link exists and choose the appropriate fix.

That balance shaped the PAH Broken Link Checker: automate repetitive inspection, preserve useful context, and avoid pretending that every unusual HTTP response has the same meaning.

Windows includes a detailed battery report that helps answer that question. You can generate it with one PowerShell command, then compare the battery's current full-charge capacity with its original design capacity.

This guide explains how to create the report, find the important values, and interpret them without confusing charge level with battery health.

Generate the Windows battery report

Open PowerShell and run:

powercfg /batteryreport /output "$env:USERPROFILE\Desktop\battery-report.html"

Windows should confirm that it saved the report to your Desktop. Open battery-report.html in any browser.

The same command works on Windows 10 and Windows 11. Administrator access is usually unnecessary, although device policies on a managed work computer may restrict the command.

Use a small PowerShell helper

If you generate reports regularly or do not want to remember the command, I published a small open-source helper:

Windows Battery Report Helper on GitHub

After downloading Generate-BatteryReport.ps1, run it from PowerShell:

.\Generate-BatteryReport.ps1

It creates battery-report.html on the Desktop by default. To generate and open the report immediately, use:

.\Generate-BatteryReport.ps1 -OpenReport

The script only calls the built-in Windows powercfg utility. It does not upload the generated report.

The three values that matter most

Windows battery reports contain several tables, but three values provide the clearest starting point.

Design capacity

Design capacity is the amount of energy the battery was rated to hold when new. Windows normally displays it in milliwatt-hours (mWh).

Treat this as the original reference value, not the amount the battery holds today.

Full charge capacity

Full charge capacity is the maximum amount of energy the battery currently reports it can hold. Normal chemical aging usually causes this figure to decrease over time.

For example:

• Design capacity: 50,000 mWh

• Full charge capacity: 40,000 mWh

The battery currently holds about 80% of its original rated capacity.

Cycle count

A charge cycle represents cumulative use equal to 100% of the battery's capacity. Two separate 50% discharges can therefore add up to approximately one cycle.

Some manufacturers do not expose cycle count to Windows. A blank cycle count does not necessarily mean the battery has completed zero cycles.

Calculate battery health percentage

Use this formula:

Battery health (%) = Full charge capacity / Design capacity × 100

Using the earlier example:

40,000 / 50,000 × 100 = 80%

This figure is better described as reported capacity health. Battery firmware readings can fluctuate slightly after charging, calibration, firmware updates, or changes in temperature.

What the percentage can and cannot tell you

Capacity health helps estimate how much runtime the battery has lost compared with its original specification. It is not a complete safety test and should not be treated as a guaranteed diagnosis.

Pay attention to physical warning signs even if the percentage appears acceptable. Stop using the laptop and seek qualified assistance if the battery is swollen, leaking, unusually hot, producing an odor, or deforming the case.

Runtime also depends on screen brightness, processor load, background applications, wireless activity, power settings, and temperature. A healthy battery can still drain quickly under a heavy workload.

Check capacity history instead of one reading

The Battery capacity history section shows how full-charge capacity changed over time. A gradual decline is expected. A sharp drop may be worth checking against recent firmware changes, usage conditions, or a second report generated after a few normal charge cycles.

One reading is useful, but a trend is more informative.

Make the report easier to read

The standard HTML report is comprehensive, but its tables can be difficult to interpret. I built Battery Health Lab to turn the report into a simpler health summary.

The analyzer runs in the browser, requires no account, and processes the selected report locally on the device. You can also enter design capacity and full-charge capacity manually if you prefer not to select the HTML file.

Common problems

“Unable to perform operation”

Confirm that you are running the command on a Windows laptop with a detected battery. Try opening a fresh PowerShell window and use an explicit output path such as the Desktop example above.

The report opens but contains no battery

Open Device Manager and check whether Windows detects the battery under Batteries. Desktop computers and some virtual machines do not expose battery data.

PowerShell blocks the helper script

You can use the direct powercfg command instead. If you change PowerShell's execution policy, understand the security implications and avoid applying a broad permanent change only to run one script.

Final takeaway

Generating a Windows battery report is simple; interpreting it correctly is the important part. Compare full-charge capacity with design capacity, examine the history rather than relying on one reading, and consider real-world runtime and physical condition alongside the percentage.

That combination provides a much clearer picture of a laptop battery than the taskbar charge indicator alone.