How to build a WordPress PDF inventory and CSV report

Large WordPress sites can accumulate thousands of PDF files without a practical way to audit their age, ownership, page counts, or usage. A custom admin-only plugin can solve this by scanning the Media Library, extracting PDF metadata, calculating page counts directly from the files, and presenting the results in a searchable report with CSV export. This creates a repeatable document-management workflow that can support WCAG 2.1 AA remediation and content cleanup efforts.

Issue background

A WordPress site with more than 2,600 PDF files needed an on-demand report that administrators could use to review and manage documents. The goal was to make it easier for internal teams to identify files that should be deleted, archived, replaced, or remediated for accessibility.

The requested report needed to include:

• The total number of PDF files in the WordPress Media Library
• The combined page count across the PDF collection
• The file name and Media Library title
• The upload date
• The WordPress user who uploaded the file
• The page count for each PDF
• A direct link to each document
• A downloadable CSV or Excel-compatible export

WordPress does not provide this type of document inventory by default, especially when the report must calculate page totals from the PDF files themselves.

Diagnosis

The Media Library already stored the attachment records and core metadata, but several important reporting requirements were missing:

• WordPress did not calculate PDF page counts.
• The standard Media Library view was not designed for auditing thousands of documents.
• There was no combined total or downloadable report.
• Administrators needed search, filtering, sorting, and pagination to work efficiently with the dataset.

The appropriate solution was a custom WordPress plugin rather than a manual export. The plugin could query PDF attachments directly, read the corresponding files, calculate page counts, and display the results in a dedicated administrative interface.

The page-count logic also needed calibration. Early totals were inflated because different metrics—such as PDF document pages and WordPress pages containing embedded PDFs—could be confused. Separating these concepts and labeling columns clearly was essential for an accurate, understandable report.

Resolution steps

1. Create an admin-only plugin page. Add a report screen under Tools > PDF Report and restrict access to authorized WordPress administrators.
2. Query PDF attachments. Retrieve Media Library attachment records where the MIME type is application/pdf. Process the complete dataset rather than relying on the current Media Library screen.
3. Collect WordPress metadata. For each attachment, retrieve the file name, attachment title, upload date, uploader, attachment ID, and public document URL.
4. Calculate PDF page counts. Read each PDF file and parse its internal page structure directly. This avoids requiring a separate desktop application or manual document review.
5. Handle unreadable files safely. Account for missing, corrupted, encrypted, malformed, or remotely unavailable PDFs. Display a clear status rather than allowing one problematic document to stop the entire report.
6. Add summary metrics. Show the total PDF count and combined PDF page count at the top of the report. Keep separate metrics clearly labeled when also reporting how many WordPress pages contain embedded PDFs.
7. Build a usable data table. Display the document details in sortable columns and add search and filtering controls for large Media Libraries.
8. Add pagination controls. Allow administrators to view 10, 25, 50, or 100 rows per page. Include numbered pagination and a direct go-to-page control when the report contains thousands of records.
9. Create a complete CSV export. Export the full report rather than only the currently visible page. Include a summary block followed by the detailed document rows.
10. Test the report on staging. Compare a sample of calculated page counts against the source PDFs, confirm uploader and date accuracy, and verify that filtering and sorting do not alter totals.
11. Refine labels based on user review. Remove ambiguous metrics such as an unexplained “Unknown” card and rename columns so administrators can distinguish PDF page counts from website-page usage.
12. Deploy and validate in production. Confirm that the report performs acceptably with the full Media Library and that only authorized users can access or export the data.

For very large libraries, the report should avoid parsing every PDF on every page load. Page-count results can be cached in attachment metadata or generated in batches, then refreshed only when a document changes. This reduces memory usage and administrative load times.

Final outcome

The completed custom plugin provided an admin-only PDF report inside WordPress. Administrators could review document metadata, search and sort the collection, choose the number of rows shown per page, move directly to a specific results page, and export the complete inventory as a CSV file.

The report also provided high-level PDF and page-count totals, giving the organization a practical baseline for document cleanup and WCAG 2.1 AA remediation. After testing, ambiguous labels were removed or clarified and the counting query was recalibrated to produce more accurate results.

A purpose-built report like this turns an unmanaged Media Library into an actionable document inventory. It can help teams assign remediation work, identify outdated files, track document ownership, and measure the scale of an accessibility initiative.

For help building custom WordPress reporting tools, auditing large Media Libraries, or improving PDF accessibility workflows, contact Freshy.