Workflow & Automation

Matching Incoming Filenames to Existing WordPress Documents

Quick answer

Filename matching works best when it narrows your options down rather than pretending every similar name is a certainty.

In practice that means: tidy up the differences that do not matter, find the parts of the name that identify the document, be careful with dates and version words, compare against what is already on the site, say how sure it is, leave the genuinely ambiguous rows for a person, and only remember a correction once a person has confirmed it.

The principle underneath all of it: how confident it is should tell you how much checking a row needs. It should never be treated as permission to overwrite.

Why exact matching is useless here

Real filenames drift:

  • employee-handbook.pdf
  • Employee_Handbook_2026_FINAL.pdf
  • staff-handbook-approved.pdf

Those are very likely the same document, and no two of those strings are equal.

Why generic fuzzy matching is not enough either

Consider:

  • finance-policy-2026.pdf
  • finance-policy-archive-2025.pdf
  • finance-procedure-2026.pdf

A similarity score will call all three close.

But “archive” changes what the document is for, “procedure” is probably a different document entirely, and whether the year matters depends on the page. No amount of string comparison works that out.

Step 1: ignore the differences that do not matter

Lowercase it. Drop the extension. Treat underscores, dashes and spaces the same. Collapse repeated punctuation.

After that, Employee_Handbook.PDF and employee-handbook.pdf are obviously the same thing.

Step 2: find the parts that identify the document

The bits that actually matter are usually the product or model, the department, the document family, a form number, or a course or program code.

Those should count for much more than the rest of the name.

Step 3: be careful about the rest

Words like FINAL, approved, latest, revised, upload, a version number, a date — those are usually noise.

Usually. The year is meaningless on a “Current Handbook” page and is the entire identity of an annual report. Which is why a global “always ignore dates” rule gets one of those wrong every time, and why these rules belong to a site rather than to the software.

Step 4: compare against more than filenames

What is already on the site gives you more to go on: the page title, the name of the custom field, a product SKU, the department, the type of resource, the existing filename.

Use the strongest identifier available. A SKU beats a filename every time.

Step 5: say how sure you are — and why

Confidence is useful for grouping rows: obvious, probably right, needs checking, nothing found.

What makes it genuinely useful is being able to see the reason:

Exact model number and matching document type; the year was ignored because this page is a current document.

That tells you something. “92%” does not.

Step 6: leave the ambiguous ones alone

If two documents are both plausible, do not quietly pick one.

Leave the row unresolved. Ten seconds of somebody’s attention is much cheaper than overwriting the wrong document.

Abbreviations

Every organization has its own shorthand:

  • HR = Human Resources
  • BUS = School of Business
  • Ops = Operations
  • Member App = Membership Application

These make an enormous difference to recurring batches — and they are specific to your site, which is why they have to be written down rather than guessed at.

Remembering corrections

This is where Pro earns its money:

You corrected this match last time. Here it is already applied.

The work you did in March is still working in September, and it belongs to the site rather than to whoever happened to run that batch.

It never stops you overriding the suggestion. It just stops you making the same correction four times a year.

Words to ignore

Some sites put the same meaningless word on every single file — FINAL, approved, upload, revised, the organization’s own initials.

Pro can learn to ignore those on your site. Not globally: “approved” is noise on one site and part of the document title on another.

Example: a 100-file quarterly batch

  • 70 match directly once the names are tidied up
  • 15 match because you have explained the abbreviations
  • 8 match because of corrections you made last quarter
  • 5 have two plausible homes
  • 2 are brand new.

So a good matcher has narrowed a hundred files down to seven decisions. That is the whole point.

The same input should give the same answer

For something that overwrites files, running it twice on the same batch should produce the same suggestions both times.

That is what makes it checkable — you can look at a row, understand why it matched, and trust that it will not decide differently tomorrow. It also means nothing is sent anywhere or guessed at: the matching happens on your site, using your filenames and what you have taught it.

Free and Pro

The free plugin does the matching, tells you how sure it is, and lets you change any row yourself. That is the whole batch, with no limits.

Pro is what stops you doing the same corrections again next quarter: your abbreviations, the words worth ignoring, and every match you have already fixed — kept with the site so the next person starts where you finished.

Summary

Good matching does not try to replace the person checking it.

It narrows a hundred files to a handful of decisions, explains why it is unsure, and remembers what you told it last time.

Related: Bulk replace files · Agencies · Higher-ed document updates