WordPress PDF links can return 404 errors even when the files still exist and the URLs appear correct. In this case, older journal PDFs stopped loading while newer editions remained accessible. Permalink changes did not help because the real problem was server-level read permissions. Correcting those permissions restored access to the files, and a separate update improved the archive’s “View more” behavior so visitors no longer jumped back to the top of the page.
Issue background
A WordPress archive contained many PDF editions spanning several decades. Visitors could open newer PDFs without issue, but older files returned a 404 Not Found response when selected.
The problem appeared after recent WordPress, Advanced Custom Fields PRO, and Divi updates, so the first concern was that a plugin or theme change had altered how legacy PDF links were generated.
The same archive also had a usability issue. Clicking the View more button loaded additional entries but automatically moved the browser back to the top of the archive.
Diagnosis
The investigation compared older broken PDFs with newer working PDFs and ruled out several likely causes.
Permalink regeneration did not resolve the issue. The PDF records and links were still present, and the files had not been deleted. The final diagnosis was that the affected files did not have the correct server read permissions.
Because the web server could not read those files, requests returned a 404-style response even though the PDFs existed on disk. This is an important distinction: a 404 response does not always mean the requested file is absent.
The archive-scroll problem was unrelated to the file permissions. Its JavaScript behavior was configured to return focus or scroll position to the top after loading more items.
Resolution steps
- Compare a broken PDF with a working PDF. Record the URL structure, upload path, custom field values, and server location for one example from each group.
- Confirm that the files exist. Use SFTP, SSH, or the hosting file manager to verify that the affected PDFs remain on the server.
- Check the stored link source. Determine whether the URL comes from the Media Library, an ACF field, a Divi module, or custom theme code.
- Rule out rewrite issues. Regenerate WordPress permalinks and test the direct PDF URL. If the direct file still fails, continue at the server layer.
- Inspect file and directory permissions. Compare the permissions and ownership of broken PDFs with those of working files in the same uploads structure.
- Restore public read access. Apply the correct read permissions to the affected files and ensure their parent directories allow the web server to traverse the path.
- Avoid overly broad permissions. Grant only the access required for the web server to read the files. Do not use world-writable permissions as a shortcut.
- Test the direct file URL. Open the PDF outside the WordPress archive page to confirm that the server now returns the file successfully.
- Retest the archive links. Verify several older and newer editions to ensure the repair applies consistently across the affected date range.
- Update the “View more” behavior. Adjust the archive JavaScript so loading additional entries preserves the visitor’s current scroll position instead of jumping to the top.
- Test keyboard and focus behavior. Confirm that the revised button remains accessible and that focus moves predictably after new content is loaded.
- Clear caches. Purge WordPress, server, CDN, and browser caches before final verification.
When only one subset of uploaded files fails, compare permissions and ownership before rebuilding templates or rewriting URLs. Legacy files may have been migrated, extracted, or uploaded under different server settings than newer content.
Final outcome
Correcting the server read permissions restored access to the older PDF editions. The existing WordPress links and files did not need to be recreated.
The archive’s View more function was also reconfigured so additional entries loaded without automatically scrolling visitors back to the top.
Both fixes were deployed successfully. Visitors could once again open the full PDF archive and browse additional entries without losing their place on the page.
The key lesson is that WordPress file errors can originate below the application layer. When a file exists but still returns a 404 response, server permissions and ownership should be checked alongside permalinks, custom fields, and theme templates.
For help troubleshooting WordPress PDF errors, server file permissions, or archive-page functionality, contact Freshy.
