What Fuzzy Matching Is, and Where It Fits in SEO

Fuzzy matching is one of those techniques that feels almost too simple to be machine learning, until you realise how many SEO problems are really just “are these two strings the same, more or less?” Redirect maps, 404 clean-ups, hreflang audits, brand-mention monitoring, they all come down to measuring how alike two pieces of text are. It is also, in my opinion, one of the easiest ways to get started with machine learning as an SEO: the payoff in automation and scale is immediate, and the limitations are easy to understand once someone spells them out.

This is the complete guide. It brings together the conceptual grounding for the fuzzy-matching module of the Introduction to Machine Learning for SEO course and my end-to-end guide to fuzzy matching for SEOs (first published in 2022, now refreshed with current libraries and code). Here is what it covers:

• What fuzzy matching is, where it came from, and the one big limitation that decides whether it is the right tool or completely the wrong one.
• The five approaches to string matching (exact, distance-based, phonetic, n-gram and TF-IDF), how each works step by step, and their limitations.
• The Python libraries you will meet: RapidFuzz, TheFuzz (the library formerly known as FuzzyWuzzy), PolyFuzz and Fuzzy Pandas, and what has changed since 2022.
• Where it fits in SEO and marketing, plus where it really does not (keyword clustering, I am looking at you).
• An end-to-end, no-code walkthrough with a free Google Sheets template for string comparisons, redirect mapping and internal-link shortlists.
• A runnable Python notebook that recreates every tab of the template and compares the libraries side by side.

Prefer to watch or listen? I walk through the original guide in this video (the theory and use cases still hold; the library recommendations are updated in the written version below):

On this page

1. What fuzzy matching is
2. The approaches to string matching
3. The Python libraries you will meet (and what changed since 2022)
4. Where fuzzy matching fits in SEO
5. End-to-end walkthrough: fuzzy matching in Google Sheets (no code)
6. The same workflow in Python: the companion notebook
7. How a fuzzy matching project actually runs
8. The Role of Fuzzy and Semantic Matching in AI Search
9. Further reading and creators to follow
10. Where to Take Fuzzy Matching Next
11. Frequently asked questions

What fuzzy matching is

Fuzzy matching is a form of string matching, a machine learning problem that dates back to at least the 1960s. At its core it measures the distance between two strings and turns that into a similarity score, or, put another way, makes an approximate match to classify the strings as equivalent, similar or distant. A survey by Hall and Dowling (1980) framed the field like this:

Approximate matching of strings is reviewed with the aim of surveying techniques suitable for finding an item in a database when there may be a spelling mistake or other error in the keyword. The methods found are classified as either equivalence or similarity problems.

Patrick Hall and Geoff Dowling, Approximate String Matching, ACM Computing Surveys (1980)

You will hear a few related terms worth untangling. Fuzzy search (also called approximate string matching) is the same idea applied to retrieving similar-but-not-identical entries from a database; fuzzy matching is the broader umbrella that encompasses it, and both deploy similar algorithms, the search version just has information retrieval as its goal. And where traditional logic is binary, a statement is true or false, information is retrieved or it is not, fuzzy logic expresses the degree to which a statement is true, which is exactly what a similarity score gives you.

In the same study, the authors describe the two broad reasons for implementing string-matching algorithms. Error correction is a corruption-correction point of view: identifying patterns in a large corpus of data, or otherwise, retrieving information based on a specified input, finding similarity mismatches and correcting the error, which is also how you de-duplicate a database. Information retrieval is all about providing an input that best describes the information you are trying to pull from the dataset, where the two risks are the program returning unwanted matches and missing the ones you need. Pause and count how many places in SEO a spelling slip or a copy-paste error creeps in, URLs, product databases, customer records, brand mentions, and you will see why this is such fertile ground for us.

It is worth dwelling on just how many SEO and marketing scenarios are secretly string-similarity problems, because once you see the pattern you find it everywhere. Any place a human types data by hand is a place errors accumulate: product databases where the same item is entered three slightly different ways, customer records with misspelled names, tagging systems that drift over time, campaign names that never quite match across advertising platforms. Fuzzy matching is the tool that reconciles all of these back to a single canonical version, which is why it turns up as often in data-cleaning and reporting work as it does in technical SEO.

The similarity problem, and the catch that matters most

Every fuzzy matching algorithm exists to solve the similarity problem: understanding how approximate, how alike, two strings are. The mathematical way each algorithm solves that is where they differ. In programmable information systems, string variation is measured by errors in spelling and typing, and early studies in the field found the culprits: mistaking one letter for another (the most common), omitting a letter, inserting one by mistake, or transposing two. Algorithms calculate distance by deciphering which of those errors separates the two strings, then scoring similarity accordingly.

And here is the catch you must internalise, because it decides everything.

String matching measures similarity at the character level, not the semantic level. It has no understanding of meaning or context. That is exactly why it is perfect for redirect mapping, where you only care whether two URLs are spelled similarly and the semantics of the content have not changed, and exactly why it is the wrong tool for deciding which internal links will genuinely help a user, where you need to understand whether two pages are actually about related things. (It can still help you build a shortlist to review, more on that below.) For anything semantic, an entity-based approach beats fuzzy matching every time. Keep that line in your head; it will save you from a lot of wasted effort and, worse, from confidently recommending the wrong method to a client.

The approaches to string matching

Since string matching was introduced, a lot of work has been done in the field, with many different algorithms and methods. String-matching methods are classified by how they calculate similarity, or how they resolve that core problem. Here is the overview, then I will go through how each one works in practice and where it falls down.

Exact matching (or direct matching) performs a direct, character-by-character comparison for the exact pattern; it is fast and highly accurate with minimal computational cost, but limited to exact matches and useless for typos. Distance-based matching uses edit distance, the minimum number of edit operations (substitutions, insertions, deletions) needed to convert one string into another; it is considered the best group for approximate matches and is flexible for typos and minor spelling differences, but it does not consider semantic meaning. Phonetic matching matches by how words sound, which handles homophones well and, with an algorithm built for the language in question, helps in multilingual environments, at the cost of lower precision and more false positives. N-gram matching detects occurrences of fixed-length substring patterns and scores similarity on shared n-grams across your dataset; it is extremely efficient and scalable for large keyword sets, but computationally heavier for long strings. And TF-IDF matching uses cosine similarity with TF-IDF, analysing the whole corpus and weighting each token as more important if it is rarer, so matches become context-sensitive rather than purely character-based.

Exact matching and the Boyer-Moore algorithm

Exact matching, elsewhere referred to as direct matching, looks for the exact pattern (or its parts) within a text, character by character. The Boyer-Moore algorithm is the classic here, one of the best-known pattern-matching algorithms and considered very fast in practice. It is designed to find every exact occurrence of a single keyword in a longer text. Here is how it works in practice:

• you have an input string (keyword) that you want to find in a dataset;
• the program lines the keyword up against the text and compares characters from the end of the keyword backwards;
• if every character matches, it records an exact match;
• if there is a mismatch, the algorithm uses what it knows about the keyword’s letters to skip ahead several positions at once, rather than one character at a time, which is what makes it so fast. It never returns partial matches.

The limitation is the obvious one: exact matching is brilliant at finding what you typed and hopeless at finding what you meant to type. One typo and it is out.

Distance-based matching: Levenshtein, Jaro and friends

Edit distance is considered the best family of algorithms for finding the distance between two strings. The edit distance between two strings s and t is the minimum number of edit operations needed to convert s into t. Here is how this works:

• you have a keyword (input) and a dataset entry;
• the program calculates the number of character changes needed to get from the input to the entry, and turns that into a distance or a similarity score.

Levenshtein distance is the workhorse (first described by Vladimir Levenshtein in 1966) and counts substitutions, insertions and deletions. Damerau-Levenshtein also counts a swap of two neighbouring letters as one edit, which suits typing errors. Jaro and Jaro-Winkler score shared characters and transpositions, with Jaro-Winkler rewarding strings that share the same beginning, which is why it is popular for names.

The limitation of this method is that it is based on a simple character distance methodology, without any comprehension of the semantic similarity between the two keywords. For instance, by raw Levenshtein distance the words HARD and HAND are more similar than HARD and HARDER, as the former needs just one replacement of a character, whereas the latter needs two additions. A human reads HARD and HARDER as far more related.

One 2026 footnote from re-testing the code for this guide: most SEO scripts do not use raw Levenshtein distance, they use a normalised score like fuzz.ratio from RapidFuzz or FuzzyWuzzy. That score is based on insertions and deletions relative to the combined length of both strings, and it actually rates HARD/HARDER (80) above HARD/HAND (75). Neither number understands meaning, they simply disagree about spelling. So always check which score your library is giving you before you set a threshold.

Phonetic matching: Metaphone and co.

Phonetic matching plays a key role in information retrieval in multilingual environments, where there can be differences in pronunciation or writing style for the same meaning. In such cases, the phonetic matching technique is also used for languages other than English, with one caveat: the classic algorithms (Soundex, Metaphone, NYSIIS, Caverphone) encode English pronunciation rules. For other languages you need a scheme built for them, such as Kölner Phonetik for German or Beider-Morse Phonetic Matching, which applies language-specific rules to names. Apache Commons Codec implements both.

Popular examples include Metaphone, Double Metaphone, Caverphone and the New York State Identification and Intelligence System (NYSIIS) phonetic code. Amongst all of these, studies have shown Metaphone excels in its performance compared to the other techniques for all types of errors (misspellings, missing letters, swapped letters, additional letters and so on), followed by Caverphone and NYSIIS. In the notebook that accompanies this post, “Lazarina”, “Lazareena” and “Lazarena” all collapse to the same Metaphone code, which is exactly the behaviour you want for catching misspelled brand or author names.

The limitation is that these algorithms are not very productive on their own: precision is low, with most of them returning a large number of false positives, and they do not detect all close matches. It is important to adapt the type of algorithm to the type of data it is going to sift through.

N-gram string matching

N-gram matching detects the occurrences of a fixed set of pattern arrays as embedded sub-arrays in an input array. In simple terms, here is how this works:

• you enter the keyword “what is string matching in machine learning” as your input;
• this can be split into 2-grams (bigrams) like “what is”, “is string”, “string matching”, “matching in”, “in machine”, “machine learning”, or 3-grams (trigrams) like “what is string”, “is string matching”, “string matching in”, “matching in machine”, “in machine learning”, or 4-grams, 5-grams, 6-grams, or one 7-gram (character n-grams work the same way, just on letters instead of words);
• all of these variations are searched for in the dataset and categorised based on the n-gram input, e.g. matches a bigram, or matches a 6-gram, with similarity based on the presence of n-grams in the dataset entry.

N-gram based algorithms are extremely efficient for quickly extracting data involving large patterns. This type of string matching has a number of applications, amongst which (but certainly not limited to):

• similarity detection for plagiarism identification;
• keyword or key-phrase detection in a large corpus of data (from the SEO world: which title or meta description matches a niche keyphrase, or parts of it);
• finding articles that mention a certain keyword pattern (how-to articles, ultimate-guide articles and so on).

TF-IDF string matching

Cosine similarity with TF-IDF is a well-established metric for comparing text, and it has been adapted for flexibly matching a query string against the values in a database column. TF-IDF analyses the corpus of words as a whole, and weights each token as more important to the string if it is less common in the corpus, as data scientist Adrian Pearl highlighted in his fuzzy-string project. In practice it is usually run on character n-grams (often trigrams), which is the default model in PolyFuzz.

Some limitations are that this approach does not take into consideration semantic similarity between the input and the database entries it finds, it needs some preprocessing, and it is not speedy when set to high accuracy.

Choosing between them, and when to go hybrid

Each approach trades off differently, and knowing the trade-offs is how you choose. Exact matching is fast and cheap but fails on any typo. Distance-based matching is flexible for spelling errors but blind to meaning and weak on words that sound alike yet are spelled differently. Phonetic matching handles exactly those homophones (and, with a language-specific algorithm, variation across languages) but is low-precision, throwing false positives and sometimes missing close matches. N-gram matching is highly efficient and scalable for large datasets and partial matches, but computationally expensive on long strings and still semantically shallow. And TF-IDF matching brings genuine context-sensitivity by weighting rarer terms, but it does not capture true semantic similarity and needs preprocessing. There is no universal best, only the best fit for your data and your tolerance for false positives versus missed matches.

Each approach has a flagship algorithm worth knowing by name: Boyer-Moore for exact matching, Levenshtein for distance-based matching and Metaphone for phonetic matching. When one method is not enough, a hybrid architecture often wins, for example Levenshtein plus Metaphone to catch misspelled-but-phonetically-similar words, or n-grams to preprocess before applying TF-IDF for contextual relevance. The important thing is to pick your method first, then compare algorithms within it, and only reach for a hybrid if a single method underperforms on your data.

The Python libraries you will meet (and what changed since 2022)

In Python you will reach for libraries that bundle these algorithms together, so swapping one for another is often a single line of code. When I first wrote this guide in 2022, the big three were Fuzzy Pandas, PolyFuzz and FuzzyWuzzy. I re-tested all of them in October 2026 for this refresh, and the landscape has shifted: RapidFuzz has largely superseded FuzzyWuzzy, to the point that FuzzyWuzzy’s successor, TheFuzz, now runs on it.

Library	Status (October 2026)	Best for
RapidFuzz	Actively maintained (v3.14), MIT licence, C++ under the hood	Your default. Same scorers as FuzzyWuzzy, much faster, plus whole-matrix scoring and many distance metrics
TheFuzz (formerly FuzzyWuzzy)	Renamed in 2021; the old FuzzyWuzzy repository is archived. TheFuzz keeps the same API but uses RapidFuzz as its engine	Keeping older scripts and tutorials working
PolyFuzz	Maintained, slower release cadence (v0.4.3, May 2025)	Comparing several models at once, grouping, TF-IDF and embedding models
Fuzzy Pandas	Unmaintained since 2019 (wraps csvmatch); still installs	Legacy only. A pandas + RapidFuzz merge does the same job

RapidFuzz (Python)

RapidFuzz is a fast, MIT-licensed string-matching library that grew out of FuzzyWuzzy’s ideas and re-implemented them in C++. It gives you the familiar scorers, ratio, partial_ratio, token_sort_ratio, token_set_ratio and WRatio, plus raw distance metrics (Levenshtein, Damerau-Levenshtein, Jaro-Winkler, Indel and more) and process.cdist, which scores every string in one list against every string in another in a single, multi-threaded call. For SEO-sized datasets (thousands of URLs or keywords), that is the difference between waiting minutes and waiting seconds. You can find the documentation here.

from rapidfuzz import fuzz, process, utils

new_urls = ["/guides/fuzzy-matching-for-seo/", "/about/"]
process.extractOne("/blog/fuzy-matching/", new_urls,
                   scorer=fuzz.token_set_ratio, processor=utils.default_process)
# ('/guides/fuzzy-matching-for-seo/', 63.8, 0)  -> best match, score, position

FuzzyWuzzy, now TheFuzz (Python)

FuzzyWuzzy is the library most older SEO tutorials use, including many of mine. It calculates the differences between sequences and patterns using edit-distance logic (strictly speaking, Python’s difflib or the python-Levenshtein ratio, both based on insertions and deletions), by working out the number of corrections needed to get from the misspelled entry to the input keyword. In 2021 it was renamed TheFuzz, and current versions use RapidFuzz under the hood, so if you have a script that starts with from fuzzywuzzy import fuzz, changing it to from thefuzz import fuzz (or from rapidfuzz import fuzz) is usually all it takes. If you want a gentle introduction to the scorers, Catherine Gitau’s tutorial is still a great place to start; the examples work as-is with TheFuzz.

PolyFuzz (Python)

In the most general sense, PolyFuzz can be used for fuzzy string matching, grouping and evaluation. It uses different fuzzy string matching techniques as a framework, such as Levenshtein distance, character-based TF-IDF and n-gram methods, and this framework can be customised to model fuzzy string matching, which is what makes the library not only powerful but also very valuable for string-matching tasks.

What are the benefits of using PolyFuzz? One huge benefit is the ability to customise the algorithm you use: with just a few lines of code you can implement different matching models depending on your need and your data. Another is that you can select the edit-distance algorithm, which matters if you don’t want to be hindered by the limitations of the basic ones (exact match or plain Levenshtein). There is an abundance of edit-distance algorithms out there, and we have only covered a small fraction of them in this article; PolyFuzz lets you plug in any distance measure (see the EditDistance documentation). Today it also wraps RapidFuzz directly and supports embedding models (Sentence-Transformers, Flair, spaCy, Gensim), which is your bridge from character-level to meaning-level matching.

Another cool thing about PolyFuzz is the ability to match, group and visualise multiple models within a single PolyFuzz instance, which you can use in model selection to compare how different algorithms perform on a sample of your dataset. The notebook below does exactly that with RapidFuzz, TF-IDF and Jaro-Winkler side by side. Check out Maarten Grootendorst’s tutorial on string matching with BERT, TF-IDF and other algorithms, leveraged via PolyFuzz, for the background from its creator.

Fuzzy Pandas (Python)

Fuzzy Pandas is a simple, lean library that lets you do fuzzy matching with pandas data frames, a fuzzy merge, essentially. You can find the project description, code snippets and docs here. It still installs and runs, but it has not been updated since 2019, so for new work I would write the merge yourself with pandas and RapidFuzz (there is a ready-made fuzzy_merge helper in the notebook).

Beyond Python’s big four

You will also see NLTK (which has edit-distance and Jaro helpers), jellyfish (phonetic codes like Metaphone and NYSIIS) and Elasticsearch (fuzzy queries built into search) used for this kind of work. Those will take you as far as you need to go as a beginner.

Where fuzzy matching fits in SEO

This is where it earns its keep, and there is a lot of it.

Redirect mapping and 404 clean-up

Redirect mapping and 404 clean-up are the classic wins: automatically match old or broken URLs to the most similar live ones, preserving link equity (especially valuable when those broken pages have backlinks) and killing dead ends, remembering it matches on the URL string, not the meaning of the content. You can do this in the Google Sheets template below (URL Redirection Mapping tab) or in Python; the full Python walkthrough is in 404 and redirect mapping with fuzzy matching in Google Colab (Python).

The community has built some great tools here too. The legendary technical SEO and Python wiz Greg Bernhardt created a simple but effective script that uses PolyFuzz to match 404s to existing content and generate a redirect list; for many of his use cases Greg releases a script and a Streamlit app, so check out his site. And Francis Angelo Reyes presented a nifty URL redirect mapping tool that used Beautiful Soup to scrape content after a redirect project and PolyFuzz to quickly check content similarity. The aim of the tool, in Francis’s words, is to:

Find identical URLs in a website migration. This is useful when you need to map out the pages from ‘current’ or ‘old’ domain to the ‘new’ domain.

Francis Angelo Reyes, Lupage Digital

Because it compares page content rather than URLs, that approach doubles as a content plagiarism checker and as a way of evaluating redirect-mapping outcomes after the fact: did each old page really land on its equivalent?

Hreflang audits

Hreflang audits catch mismatches between the URLs your hreflang specifies and the URLs your map says should be there, which prevents real revenue leaks on multilingual ecommerce and lead-gen sites.

Duplicate detection and string similarity checks

Duplicate and near-duplicate detection spots accidental content overlap or cannibalisation fast, brilliant for large enterprise sites with accidental section duplication, and best run on metadata (titles, headings, URLs) or, for plagiarism, at paragraph level, since fuzzy matching works best on shorter strings. The simplest version is finding the similarity between two strings, keywords, URLs or titles, which is exactly what the String Assessment tab of the template does: paste a list, get each item’s nearest neighbour and a score, and the near-identical pairs jump out.

Competitor analysis of URLs and titles

Greg Bernhardt also created a script and Streamlit app using PolyFuzz to perform a competitive analysis of URLs and other site data, such as titles. The aim is to find differences between your ranking URL structure, titles and keyword use and those of your competitor, discover where they are outranking you (via the Semrush API), and highlight opportunities and quick wins.

Title-versus-query alignment

A favourite of mine, title-versus-query alignment, compares ranked queries to page titles to spot click-through-rate opportunities and better align the title with how users actually search, brilliantly demonstrated in Natzir Ruiz’s guest tutorial on the MLforSEO blog, automatically optimising metadata with FuzzyWuzzy and OpenAI, which pairs fuzzy matching with generative AI.

Internal linking: a shortlist, not a decision

Based on a content extraction of your pages from Screaming Frog, you can also use fuzzy matching to find similar pages to link to, within the same topic cluster or across page groups. I want to be careful here, because this is where the character-versus-meaning catch bites hardest. The recommendation is to use this only for pages that are similar in nature in terms of content structure (product pages with product pages, say), as otherwise you will be comparing apples to oranges. It will not evaluate content semantics as part of the process, so be aligned on the limitations of fuzzy matching before you start.

It is also best to keep the comparisons relatively small: compare paragraphs, intros or titles rather than the entire content of the page. Whilst this is great for experimentation, it is very important to review every recommendation and sense-check it afterwards, to make sure the links you add are sensible and genuinely useful to the reader. Think of the output as a shortlist to review. When you want link suggestions based on what pages are actually about, entity analysis or embeddings are the right tools.

Beyond core SEO

Fuzzy matching is genuinely useful across marketing: comparing PPC ad copy for similarity (yours or competitors’, using Levenshtein, cosine or n-grams) to improve variations and align weaker campaigns to winning ones; social hashtag normalisation, grouping near-identical hashtags to capture every post on a topic; catching brand mentions across social posts, captions and comments even when your name is misspelled; and matching product-category or product-name terms unique to your ecommerce brand. It is also a wonderful conversation-starter with siloed teams, PPC, social, product, customer service, all of whom have data you can share scripts with and learn from.

Keyword clustering: possible, but not recommended (here’s why)

PolyFuzz, and fuzzy matching in general, can be used for clustering and grouping keywords during keyword research, or backlinks during backlink research. The code for doing that is in the PolyFuzz API documentation itself, and for a small set of closely aligned keywords where the topics really do track the keyword text, it can be a quick-and-dirty first pass.

However, as Lee Foot found after experimenting with PolyFuzz for keyword clustering, this is not at all an ideal or recommended way to do keyword clustering at scale, for the reasons in the theory section above. Fuzzy matching looks at shifts between characters, as opposed to the semantic relationships between the words in a cluster. As Lee put it:

While it got the job done, there were always some head-scratching clusters which I felt the original result could be improved on. Words that shared a similar pattern of letters would be clustered even if they were unrelated semantically.

Lee Foot, Search Engine Journal

You can see it for yourself in section 7 of the notebook: “audio editing” lands in the same group as “seo audit” because they share letters, while “link building” and “backlink outreach”, which mean nearly the same thing, barely register as similar. For keyword clustering, use ML clustering on embeddings or entities instead.

End-to-end walkthrough: fuzzy matching in Google Sheets (no code)

The quickest way to find out how similar two strings are does not involve Python at all. You can use fuzzy matching as an Apps Script function in Google Sheets (alongside the other Google Sheets formulas I use for SEO analytics), or the Fuzzy Lookup add-in in Excel.

If you prefer Excel, Microsoft’s Fuzzy Lookup is developed as an add-in, and you can find a great walkthrough of fuzzy lookup methods here. Essentially, it is an advanced version of VLOOKUP, using maths to calculate the probability that what it finds matches your search entry, which means it works even when characters (numbers, letters, punctuation) do not line up exactly. I find the fuzzy-lookup approach in Google Sheets with Apps Script a bit more nuanced, easier to install and get going with, and more user-friendly, so that is what my template uses.

The template has three working tabs, each for a different job, plus a tab for your inlinks report. Make a copy (it goes into your own Google Drive, and nothing is shared back with me) and follow the steps written at the top of each tab.

Copy the free fuzzy matching Google Sheets template ✨

Step 1: Get your data

Crawl your website with Screaming Frog (or any crawler that lets you export page content). Depending on the job, you will want a list of keywords or titles, your old and new URLs, or a custom extraction of each page’s body content alongside its URL. For internal linking, also export Screaming Frog’s inlinks report.

Step 2: Assess string similarity in seconds (String Assessment & Comparisons tab)

Paste whatever you want to compare, titles, keywords or headings, into column A. Column B returns the most similar string from the rest of your list and column C the similarity score. Under the hood it is a custom function, =findsimilartext(input, range, 0.3, "text"), where 0.3 is the minimum similarity before it returns a match (an empty cell and 0% mean nothing passed the bar). In the example below, “pytrends” and “pytrend” score 92% and “lda topic modeling” vs “lda topic modelling” scores 87%, the kind of near-duplicates that hint at cannibalisation or a messy keyword list.

Step 3: Map your redirects (URL Redirection Mapping tab)

Paste your old URLs in column A and your new URLs in column B. For each old URL, the sheet tells you whether it found a direct match or a mismatch (column C), the most similar URL from the new list (column D) and the similarity score (column E). Direct matches at 100% are your confident one-to-one redirects; mismatches with a middling score are the ones to review by hand.

Step 4: Shortlist internal link opportunities (Internal Linking Opportunities tab)

Paste your content extraction in column A and the corresponding URLs in column B. You get a verdict (column C; a score of 100% means the content is duplicated, which is an issue in itself), the most similar page (D), the similarity score (E) and where to link to (F). If you paste your Screaming Frog inlinks report into the “Paste your Inlinks report here” tab, column G also tells you whether that link already exists. Two pro tips from building it: clean special characters ([$&+,:;=?@#|'<>.^*()%!-]) and new lines (\n) with Find and Replace, regex enabled, replacing them with a space; and resize your rows to the default height and clip the text in column A, or the sheet becomes unreadable.

Remember the caveats from earlier: this is a shortlist to sense-check, best used on pages with similar structure and on short extracts.

Step 5: Review, threshold, act

Whatever the tab, the last step is the same: sort by similarity, decide on a threshold from a sample you have checked by hand, and review everything in the grey zone. The Apps Script code in my template comes from the String Similarity, Find Best Match in JavaScript & Google Sheets video, and Stephen Brown’s string-similarity-js is another neat option if you want to build your own.

Start mapping your redirects, easily ✨ Copy the template

The same workflow in Python: the companion notebook

When your lists get into the tens of thousands, or you want to test several algorithms against each other, move to Python. The companion notebook recreates every tab of the Sheets template and runs end to end on sample data, so you can see each step before you plug in your own exports: the notebook on GitHub

1. Scorers 101: ratio, partial_ratio, the token scorers and WRatio, plus the HARD / HAND / HARDER comparison.
2. String assessment: nearest neighbour for every keyword or title in a list.
3. Redirect mapping: old to new URL on the path, bucketed into “confident”, “review by hand” and “no good match”.
4. Internal-link shortlist: most similar page per extract, with a check against your existing inlinks.
5. Library comparison: RapidFuzz vs TheFuzz vs PolyFuzz (three models side by side, plus grouping), and a pandas + RapidFuzz replacement for Fuzzy Pandas.
6. Phonetic matching with Metaphone and NYSIIS.
7. Why not keyword clustering, with an optional embeddings comparison.

It works in Google Colab with no setup beyond the first install cell.

How a fuzzy matching project actually runs

It helps to see the shape of a real job. Take redirect mapping, the most common one. You start with two lists: the old URLs (from your pre-migration crawl, or your backlink and analytics exports) and the live URLs (from a fresh crawl of the new site). You run a distance-based or hybrid algorithm to score every old URL against every live URL, keep the best match for each, and bucket the results by similarity score: a near-100% score is a confident one-to-one redirect, a middling score is a partial match to review by hand, and a low score flags an old URL with no good destination, which you either send to a relevant category page or accept as a genuine 404. Set a sensible similarity threshold and you have turned a week of manual spreadsheet work into a first-pass map you can review in an hour. The 404 clean-up job is almost identical; only the input list changes.

The workflow for improving your results is just as repeatable. Identify the kind of error or variation you are dealing with, pick the method that targets it, compare the specific algorithms within that method, and only build a hybrid architecture if a single method underperforms. Catching misspelled brand names across languages points to phonetic; searching a huge keyword set for partial matches points to n-grams; a job where context and term rarity matter points to TF-IDF. Because the popular Python libraries bundle many algorithms behind a near-identical interface, the cost of testing one against another is close to zero, so test on your own data before you commit. The right choice is empirical, not theoretical, and the comprehensive reference guide that maps each algorithm to its approach, similarity calculation, advantages and limitations makes narrowing it down far quicker.

The Role of Fuzzy and Semantic Matching in AI Search

This character-versus-meaning distinction matters more, not less, in the AI-search era, and I dug into exactly why in a longer piece for iPullRank, Fuzzy Matching and Semantic Search. The core argument is that modern retrieval runs on two layers at once. Fuzzy, lexical matching (edit distance, n-grams, BM25) repairs messy input and tolerates typos, while semantic matching via embeddings captures paraphrases, synonyms and intent. Leading systems combine both in a hybrid pipeline and then rerank the candidates with fusion methods, because neither layer alone is enough.

Three practical consequences follow for anyone optimising for AI search. First, because these systems extract short, self-contained passages, you should map clustered question variants to tight H2 and H3 sections an LLM can lift with high confidence and no hallucination risk. Second, entity consistency, unified NAP and stable, machine-readable schema, reduces the ambiguity that makes a system distrust and skip your content. And third, the metric that matters shifts from ranking to retrieval inclusion: in a retrieval-augmented pipeline, being selected as a candidate passage is step zero. Fuzzy matching keeps your technical foundations clean so you stay eligible; semantic structure is what actually gets you chosen.

Further reading and creators to follow

Throughout this guide I have featured the work of amazing creators in the SEO and data space. If you want to dig deeper, here are some great resources on fuzzy matching and its use cases:

• Maarten Grootendorst has written a great intro to fuzzy matching in Python; jump into the PolyFuzz code directly here.
• The RapidFuzz repository and docs explain every scorer and distance metric, with examples.
• Raoof Naushad has written another great guide to the different fuzzy matching methods.
• If you are a video-learning type of person (like me), these two walk you through fuzzy matching:
  • String Similarity, Find Best Match in JavaScript & Google Sheets (the code for my template comes from this video)
  • Google Colab Tutorial: Fuzzy Match Lookup with Google Sheets Data Using Python Fuzzy Pandas
• Needless to say, the docs will be your best friend when building custom tools, so read the documentation.
• Another cool string-similarity JS script by Stephen Brown.

Where to Take Fuzzy Matching Next

So, now you know how fuzzy matching works, its benefits, its limitations and its use cases for SEO, and you have a template and a notebook to go and test it yourself. It is undoubtedly one of the easiest ways to get started with machine learning as an SEO, with real automation and scalability benefits, but also some pretty significant limitations, which make it useful in certain contexts and useless in others.

The Introduction to Fuzzy Matching module inside Introduction to Machine Learning for SEO takes you into the practicals: 404 and redirect mapping, and competitor or internal metadata opportunity analysis, all hands-on. And remember the golden rule: fuzzy matching is for character similarity. When you need meaning, reach for entity analysis instead.

Thank you for reading, and happy learning!

Frequently asked questions

What is string matching?

String matching in machine learning is a problem that dates back to at least the 1960s. It measures the distance between two strings and, on that basis, calculates a similarity score between them, or makes an approximate match that classifies the strings as equivalent, similar or distant. Fuzzy matching is the approximate (not exact) version of string matching.

What are the different methods in string matching and what do they do?

1. Exact matching looks for the exact pattern within a text, character by character (Boyer-Moore is the classic algorithm). 2. Distance-based matching, most prominently Levenshtein and Jaro, evaluates the distance between two strings by calculating the minimum number of edit operations needed to convert one into the other. 3. Phonetic matching (e.g. Metaphone) checks strings for phonetic similarities and differences; for languages other than English, choose an algorithm built for that language. 4. N-gram matching detects the occurrences of fixed-length word or character sequences shared between strings. 5. TF-IDF matching analyses the corpus of words as a whole and weights each token as more important to the string if it is less common in the corpus.

What are the most commonly used fuzzy matching libraries?

In Python: RapidFuzz (the fast, actively maintained default), TheFuzz (the new name for FuzzyWuzzy, which now runs on RapidFuzz), PolyFuzz (a framework for comparing and grouping with several models, including embeddings) and Fuzzy Pandas (a fuzzy merge for data frames, unmaintained since 2019). Without code, use a fuzzy-lookup Apps Script in Google Sheets or the Fuzzy Lookup add-in in Excel.

Is FuzzyWuzzy still maintained, and should I use RapidFuzz instead?

FuzzyWuzzy was renamed TheFuzz in 2021 and the original repository is archived. TheFuzz keeps the same functions but uses RapidFuzz under the hood. For new projects, use RapidFuzz directly: same scorers (ratio, partial_ratio, token_sort_ratio, token_set_ratio, WRatio), much faster, and an MIT licence. For old scripts, swapping the import to thefuzz or rapidfuzz usually just works.

What can fuzzy matching be used for in SEO work?

Fuzzy matching can be used for: finding the similarity between two strings (keywords, URLs, titles), which helps with cannibalisation and duplication analysis; mapping redirects and matching 404s to existing content to generate a redirect list; evaluating redirect-mapping outcomes and content plagiarism; competitor analysis of URL and title differences to find keyword-use opportunities; hreflang audits; title-versus-query alignment; and shortlisting internal-linking candidates in the same topic cluster or across page groups (to review by hand).

What is fuzzy matching not recommended for in SEO work?

Fuzzy matching is not recommended for large-scale keyword clustering in keyword research, as the models typically used have no semantic comprehension: words with similar letters get grouped even when they are unrelated. The same goes for any decision that depends on meaning, like which internal links genuinely help a user. For big datasets and meaning-based tasks, use embeddings, ML clustering or entity extraction instead.

Related glossary terms

• Fuzzy (string) matching
• String matching
• FuzzyWuzzy / RapidFuzz / PolyFuzz
• Entity extraction (NER)
• Clustering