SEO Text Analysis Tools: Word Frequency, Length Checkers, Snippet Preview and More

Some tools do more than reformat text — they answer SEO questions directly. Is this title too long for the results page? Which words dominate this page? Are several pages competing for the same keyword? What does this robots.txt actually block? Which location-and-service combinations should a local campaign target?

This guide covers SeoWolf's SEO analysis tools: what each measures, where the measurement can mislead you, and the real workflows they fit.

The Tools at a Glance

Word Frequency Counter

What It Does

A frequency count reduces a body of text to a ranked list of its words and how many times each one occurs. It is the simplest possible summary of what a text is about, and often a surprisingly honest one.

What the ranking reveals

Strip out the structural words and the top twenty remaining terms are, roughly, the subject. If they are not the subject you intended, the text is about something other than what you meant it to be about.

Stop words dominate without filtering

the, and, of and to will always top an unfiltered count. Removing them first is what makes the result meaningful.

Common applications

Profiling a competitor's page, checking a draft against its intended topic, or finding the terminology that recurs across a set of customer reviews.

Word Frequency Is a Hash Map and Three Hard Decisions

The classic implementation is a hash map from token to count, or in shell tr -s '[:space:]' '\n' | sort | uniq -c | sort -rn. The algorithm is settled. The preprocessing is where results are won or lost.

Raw counts favour long documents

A word appearing 40 times in a 10,000-word page is rarer than one appearing 5 times in a 200-word page. Comparing documents of different lengths on raw counts is meaningless — normalise to a rate, or use TF-IDF, which weights each term by how unusual it is across the whole corpus rather than how often it appears in one document.

Case and punctuation change the answer

Shoes, shoes and shoes, are three keys unless you fold case and strip punctuation first. That alone typically merges 10-20% of a naive count's distinct entries.

Bigrams carry meaning unigrams lose

Single-word counts destroy phrases. running and shoes appearing frequently does not establish that running shoes appears at all. Counting adjacent pairs alongside single words recovers most of what tokenisation threw away.

In a Real Workflow: What 300 Customer Reviews Are Actually Telling You

Three hundred reviews is too many to read carefully and too few to hand to a data team. It is exactly the size where a frequency count earns its keep.

Running it

Paste the review text, strip stop words, and count. The ranked output shows which words customers reach for repeatedly — and those words are the vocabulary your landing page should be using.

The interesting result is usually a surprise

A software company expects features and interface at the top. The actual top terms are support, quickly and refund. That is a finding: customers are talking about the service experience, not the product, and the page selling on features is answering a question nobody asked.

Where frequency misleads

Counting cannot tell praise from complaint. support at the top might mean support is excellent or unbearable. Use the count to find what people talk about, then read a sample of those specific reviews to learn what they are saying about it.

Try it: Word Frequency Counter on SeoWolf's Notepad.

Line & Word Statistics Counter

What It Does

A statistics pass reports the basic dimensions of a text: how many lines, how many words, how many characters.

The value of counting first

Before processing a list it is worth knowing its size, and after processing it is worth knowing whether the size changed as expected. A filter that was meant to remove a handful of rows and removed half of them has gone wrong, and the count is what reveals it.

Comparing before and after

The difference between two counts is a check on every list operation. Deduplication that removes nothing means the list was already clean, or the comparison rule was wrong.

Where it fits

Run it at the start to know what you have, and after any step whose effect you cannot see at a glance.

What wc Counts and What It Does Not

wc -l, wc -w and wc -c give lines, words and bytes. Each definition has an edge that surprises people.

The final line without a newline

wc -l counts newline characters, not lines. A file whose last line has no trailing newline reports one fewer than it contains. Concatenating two such files also joins their last and first lines into one — a genuine data corruption that no error reports.

Bytes versus characters

wc -c counts bytes; wc -m counts characters. On any non-ASCII text they differ, and the one you want depends on whether the downstream limit is a storage constraint or a display one.

Word definition

wc -w splits on whitespace, so state-of-the-art is one word and hello,world is one word. Anything expecting a tokeniser's definition will disagree.

Counting distinct values

wc -l after sort -u gives distinct lines, and the difference against the raw count is the duplicate volume. That pair of numbers is usually more informative than either alone.

In a Real Workflow: The Sanity Check That Catches a Broken Export

A client sends the keyword export. You process it, build a plan, present it, and someone asks how many terms were in the original file. Nobody counted.

Count at the door

Recording the line count of every file as it arrives takes seconds and settles a whole class of later argument. When the processed list is 4,200 rows and the source was 12,000, you can say exactly where the other 7,800 went.

Catching truncated files

Exports fail quietly. A tool that caps at 1,000 rows returns exactly 1,000 rows and no warning. A round number in a line count is almost always an export limit rather than a coincidence, and spotting it before analysis saves rebuilding the whole thing.

Reporting the funnel

12,000 raw, 8,400 after deduplication, 5,100 after removing brand terms, 900 with meaningful volume. That sequence is more persuasive than any single number, because it shows the work.

Try it: Line & Word Statistics Counter on SeoWolf's Notepad.

Append Character Count per Line

What It Does

This appends each line's character count directly to that line, turning a plain list into a measured one that can be sorted, filtered or eyeballed against a limit.

Why measure in place

Character limits are everywhere in marketing work — title tags, meta descriptions, ad headlines, SMS bodies, database columns. Knowing which specific entries breach a limit matters more than knowing that some of them do.

The advantage over a spreadsheet formula

A formula puts the count in an adjacent cell that has to be kept aligned with the text. Appending it to the line keeps measurement and subject together as one string, which survives copying, sorting and pasting between tools.

What comes next

Once every line carries its count, sorting by length puts the worst offenders at the top, and filtering by number isolates exactly the set that needs rewriting.

Character Counts Depend on What You Mean by Character

awk '{print $0 " " length($0)}' appends a length to every line. Whether that number is the one you need depends on an encoding question most tooling leaves implicit.

Bytes, code points, and what users see

In UTF-8, café is four characters and five bytes. An emoji is one visible character and four bytes. A flag emoji is one visible character built from two code points. wc -c counts bytes, wc -m counts characters, and neither necessarily matches what a platform's own validator counts.

Where the target system enforces a byte limit — a database column declared in bytes, for instance — a character count will pass text that the insert then rejects.

Combining marks split the difference

é can be one code point or two: e plus a combining accent. Both render identically. A naive count reports different lengths for two visually identical strings, and normalising to NFC first is what makes them agree.

Practical guidance

For SERP and ad limits, count characters rather than bytes, normalise first, and leave headroom. Exact-fit strings are the ones that break when the data changes underneath you.

In a Real Workflow: Finding Which Ad Headlines Will Be Truncated Before Launch

Every ad platform truncates headlines past a limit, and it does so silently. The ad still runs. It just runs with the end of your message cut off, and nothing in the interface tells you which of your ninety variants are affected.

Measuring the whole set at once

Paste the headline list, append the character count to each line, and the overruns are immediately visible. Sorting by that count puts every variant at risk at the top of the list, in order of severity.

Why the limit is not the real threshold

Aim comfortably under the maximum rather than exactly at it. Platforms differ on whether they count spaces and punctuation the way you do, and a headline sitting one character under the documented cap is one dynamic keyword insertion away from being cut anyway.

The same check, other places

Meta descriptions before a bulk upload, subject lines before a send, push notification bodies before a schedule. Anywhere text meets a hard limit, measuring the full set beats spot-checking a few.

Try it: Append Character Count per Line on SeoWolf's Notepad.

Append Word Count per Line

What It Does

This appends the number of words in each line to that line. Where character counts answer "will this fit", word counts answer a different question — how specific is this phrase.

Word count as a proxy for intent

In keyword work, length correlates with specificity. One- and two-word terms are broad and heavily contested. Four- and five-word terms are narrower, lower in volume, and usually much clearer about what the searcher actually wants.

Making the split visible

Measuring every line turns a shapeless keyword export into something you can segment. The head terms and the long tail separate cleanly once each row carries its own count.

Then sort or filter

Sorting by word count groups similar specificity together. Filtering isolates a band — everything with four or more words, for instance — as a starting set for long-tail content planning.

Word Counting Is a Tokenisation Decision

awk '{print $0 " " NF}' gives a word count per line by splitting on whitespace. That definition is a choice, and different tools make it differently — which is why two word counts of the same text disagree.

Hyphens and apostrophes

Is state-of-the-art one word or four? Is don't one or two? Whitespace splitting says one and one. A tokeniser splitting on non-alphanumerics says four and two. Neither is wrong; they answer different questions. Just do not compare counts produced by both.

Runs of whitespace

Splitting on a literal single space turns a double space into an empty token, inflating the count. awk's default field splitting handles runs correctly, but a naive split(' ') in most languages does not — that is the usual source of counts that are mysteriously a few too high.

Numbers and punctuation as words

Top 10 tips! is three words plus a number, or four tokens, depending on whether digits count. For keyword length banding it rarely matters, as long as one rule is applied to the entire list. Mixing rules within a dataset is what produces bands that do not mean anything.

In a Real Workflow: Splitting a Keyword Export Into Head and Long Tail

A keyword export of six thousand rows is not a strategy. Two piles — the handful of broad terms you will fight for and the many specific ones you can win quietly — is the beginning of one.

Segmenting by length

Append a word count to every row, then split the list at three words. Below the line sits the competitive head: high volume, high difficulty, slow to move. Above it sits the tail: lower volume per term, far more terms, and dramatically easier to rank for.

What each pile is for

Head terms justify your genuinely best pages and a long timeline. Tail terms justify volume and speed, and they convert better because the searcher has already told you exactly what they want.

Where the budget usually goes wrong

Programmes fail by spending everything on the head pile, where results take a year, and neglecting the tail, where results take weeks. Seeing the two piles side by side with real counts makes that imbalance an argument you can win in a planning meeting.

Try it: Append Word Count per Line on SeoWolf's Notepad.

Meta Title Length Checker

What It Does

This measures a batch of title tags against the width search results typically display, flagging those that will be cut off.

The working limit

Around 60 characters on desktop, though the real constraint is pixel width rather than character count. Titles beyond that truncate with an ellipsis.

Both extremes cost you

Too long and the end of the message disappears — often the part carrying the differentiator. Too short and you have left space unused that could have earned the click.

What to do with the flagged set

Front-load. Move the distinguishing words to the start so that whatever survives truncation is the part that matters.

Validating Titles in a Build Pipeline

Title length is one of the few SEO properties that can be checked deterministically at build time, which makes it worth automating rather than auditing periodically.

Check uniqueness before length

Duplicate titles across many URLs almost always indicate a template that omits a distinguishing variable. That is a more serious defect than length and is trivially detectable — count titles, compare against the count of distinct titles, fail if they differ.

Length is a warning, not an error

Pixel width is the real limit and cannot be computed exactly without font metrics. Treat a character threshold as a warning that prompts review, and reserve build failures for missing or duplicated titles, which are unambiguous.

Watch for template concatenation

Many systems append a site name to every title. A check that measures the raw field rather than the rendered output will pass titles that truncate in production. Validate the final rendered string, including any suffix the template adds — that is what the search engine sees.

In a Real Workflow: The Cheapest Traffic Win Available on Most Sites

Rewriting title tags does not require new content, developer time or budget. On a site that has never had them reviewed, it is reliably the highest return per hour of any SEO work.

Where the wins are

Pages ranking positions four to ten with poor click-through rates. They already have the visibility; they are failing to convert impressions into visits, and the title is the largest single factor in that.

What actually changes performance

Specificity. Project Management Software says nothing that the nine results around it do not. Project Management Software for Agencies Under 20 People tells a particular searcher this is for them — and loses nothing by excluding everyone else, because they were never going to convert.

Measure it properly

Record click-through rate for the affected queries before the change, wait a few weeks, and compare at a comparable position. Rankings may not move at all; clicks should.

Try it: Meta Title Length Checker on SeoWolf's Notepad.

Meta Description Length Checker

What It Does

Meta descriptions have no fixed character limit. What they have is a display width, and Google truncates whatever exceeds it — usually somewhere around 155 to 160 characters on desktop, and less on mobile.

What the checker reports

It measures a batch of descriptions against typical display limits and shows which ones fall outside. Both directions matter: too long gets cut mid-sentence, and too short wastes space that could have earned the click.

Why descriptions still deserve the effort

They are not a ranking factor. They are a click-through factor, and click-through is what turns a ranking into traffic. A page sitting at position four with a compelling description can outperform position two with a truncated one.

The rewrite that follows

Put the reason to click in the first hundred characters. Anything after that is a bonus that may or may not survive truncation.

Why Your Meta Description Limit Is Measured in Pixels

The character count everyone quotes is a proxy. Google truncates on rendered width, not character count, which is why two descriptions of identical length can truncate differently.

Width varies per character

In a proportional typeface, i and l are narrow while m and W are wide. A 160-character description of mostly narrow letters can render shorter than a 150-character one full of capitals. The real desktop budget is roughly 920 pixels; character counts are a convenient approximation of it.

Google rewrites you anyway

A substantial share of displayed descriptions are not the ones in the markup. Google frequently substitutes text from the page body when it judges that a better match for the query. Optimising length is worthwhile; assuming your text will be shown verbatim is not.

What to validate in a build pipeline

Check presence, uniqueness across the site, and a sane length band. Uniqueness is the one worth failing a build over — a duplicate description across hundreds of URLs is a template bug, and it is far more damaging than a description that runs ten characters long.

In a Real Workflow: Auditing 400 Meta Descriptions Before a Site Migration

Migrations are when metadata problems surface all at once. Descriptions written by six people over four years, some auto-generated, some copied between pages, all about to be carried onto a new platform without review.

Running the check first

Measure the whole set before migrating anything. The output splits into three actionable piles: over the limit and truncating, far under and wasting space, and identical to another page.

Deal with the duplicates first

Duplicated descriptions are the worst of the three. They usually mean a template is generating the same text across a whole section, which tells searchers nothing about why one page differs from another. That is a template fix, and fixing it once resolves hundreds of pages.

Then prioritise by traffic

Do not rewrite four hundred descriptions by hand. Sort the problem set by the traffic each page actually receives and rewrite the top fifty properly. The rest can wait for a template default that is at least accurate.

Try it: Meta Description Length Checker on SeoWolf's Notepad.

Google SERP Snippet Preview

What It Does

A SERP preview renders a title, URL and description the way a search result displays them, so you can see the listing before it exists rather than after.

What it shows you

Where the title truncates. Whether the description reads as a complete thought or stops mid-sentence. How the two work together as a single unit of persuasion.

Why writing blind fails

Titles and descriptions are written in a CMS field that gives no indication of display width. A headline that reads perfectly in the editor can lose its last four words in the results page — and those are usually the words carrying the offer.

The habit worth building

Preview before publishing, not after a click-through rate report shows something is wrong.

SERP Previews Are an Approximation, Not a Contract

A preview tool renders your text at roughly the width Google uses. It cannot promise the live result will match, because several things happen between your markup and the rendered listing.

Google rewrites titles and descriptions

A substantial share of displayed titles are not the ones in the <title> tag. Google substitutes text from headings, anchor text or body content when it judges that a better answer to the query. Descriptions are replaced even more often.

Truncation is pixel-based

The limit is rendered width, not character count — around 600 pixels for titles on desktop. Narrow characters fit more; capitals fit fewer. Any character-count rule is a proxy for the real measurement.

Query-dependent rendering

Matched terms render in bold, which changes width. Sitelinks, dates and rich result markup all shift the space available. The same page previews differently against different queries.

What to build against

Treat the preview as a sanity check, keep titles comfortably under the limit rather than exactly at it, and validate uniqueness across the site — that one is deterministic and worth automating.

In a Real Workflow: Rewriting the Snippet Before Rewriting the Page

A page ranks fourth and earns almost no clicks. The instinct is to rewrite the page. Check the snippet first — it is a far cheaper fix and frequently the actual problem.

Diagnosing from the result, not the page

Preview the listing as it currently appears. A truncated title, a description that starts with boilerplate, or a headline that answers a different question than the query all suppress clicks regardless of how good the page is.

What usually needs to change

Put the distinguishing benefit in the first fifty characters of the title. Open the description with the reason to click rather than a company introduction. Neither requires touching the page content.

Measure the right thing

Watch click-through rate for that query in Search Console, not rankings. A snippet rewrite should move clicks at an unchanged position — that is the whole point of it.

Try it: Google SERP Snippet Preview on SeoWolf's Notepad.

Keyword Cannibalization Checker

What It Does

Cannibalization is what happens when several pages on one site target the same search intent. Instead of one strong page, the site fields three mediocre ones that compete with each other for the same result.

How it happens without anyone deciding to do it

Nobody sets out to publish four pages about the same thing. It accumulates: a blog post in 2022, a landing page in 2024, a category description that drifted toward the same topic, and a guide nobody remembered existed.

What the checker does

It takes a list of pages alongside their target keywords and flags where the targets overlap, so the collisions surface as a list rather than as an unexplained ranking problem.

Why the fix is usually consolidation

Merging competing pages into one and redirecting the others concentrates the signals that were being split. The combined page frequently outranks anything the separate versions managed alone.

Detecting Target Overlap Across a Page Inventory

Overlap detection is a pairwise comparison problem, and the naive implementation gets expensive fast: comparing every page against every other is O(n²), which is fine at 200 pages and unpleasant at 50,000.

Exact matching is not enough

Comparing target keyword strings for equality catches only the obvious cases. running shoes and shoes for running collide in the index and not in a string comparison. Normalising first — case-folding, sorting tokens, stripping stop words — catches far more of the real overlaps.

Where the signal actually is

The strongest evidence of cannibalization is not in your keyword mapping at all; it is in Search Console. Filter to a single query and look at which pages received impressions for it. If the URL receiving impressions changes over time, the index is switching between candidates — which is cannibalization observed directly rather than inferred.

Structuring the check

Group by normalised target, then report any group with more than one URL. That is a single pass with a hash map rather than a pairwise sweep, and it scales to any inventory you are likely to have.

In a Real Workflow: When Rankings Drop and Nothing on the Page Changed

A page that ranked fourth for two years slips to eleventh. Nothing about it changed. No algorithm update landed. The backlink profile is intact. Before auditing the page itself, check what else on the site is now competing with it.

The usual culprit

Someone published something adjacent. A new blog post, a refreshed service page, a landing page for a campaign — and it targets close enough to the same intent that the search engine now has to choose between them. It often chooses the newer page, which is weaker, and both end up lower than the original was alone.

Diagnosing it

Export your pages and their target keywords and run the overlap check. Collisions show up as pairs. Where two pages target near-identical intent and one recently dropped, you have your explanation.

Deciding what to do

Consolidate when both pages serve the same intent — merge the better content into the stronger URL and redirect the other. Differentiate when the intents are genuinely distinct but the targeting drifted; retarget the newer page rather than deleting work.

Try it: Keyword Cannibalization Checker on SeoWolf's Notepad.

Cartesian Product (Keyword Combiner)

What It Does

A Cartesian product takes two lists and produces every possible combination of one item from each. Ten modifiers and forty product names give four hundred phrases, generated exhaustively rather than remembered.

Why generate rather than brainstorm

Human brainstorming is patchy. You will produce cheap running shoes and best running shoes and forget running shoes near me entirely — not because it is a bad term, but because attention ran out. Exhaustive generation has no attention to run out of.

The obvious use

Modifiers crossed with products. Cities crossed with services. Brands crossed with comparison words. Any two dimensions where every combination is potentially a real search.

The necessary second step

Most generated combinations are nonsense. Generation is cheap; validation is the work. Push the output through a volume checker and keep only the phrases people actually search for.

Cartesian Products Grow Faster Than People Expect

The output size is the product of the input sizes, and that multiplication catches people out. Two lists of 1,000 produce a million rows. Add a third dimension of 50 and you have fifty million.

Nested loops are the whole algorithm

Two nested loops, or in shell for a in $(cat list1); do for b in $(cat list2); do echo "$a $b"; done; done. The logic is trivial; the resource profile is not.

Generate lazily where you can

Materialising the full product into memory is the usual mistake. Generators and iterators emit combinations one at a time and keep memory flat regardless of output size. In SQL the same thing is a CROSS JOIN, and the database streams it rather than building it.

Cap before you generate

The practical guard is to multiply the input lengths first and refuse if the result exceeds a sane ceiling. Failing fast with a clear message beats producing a five-million-line file that no downstream step can process anyway.

In a Real Workflow: Building a Local Landing Page Matrix Without Missing a City

A service business covering sixty towns with eight services has four hundred and eighty possible service-and-place pages. Nobody assembles that list by hand correctly.

Generate the full grid first

Cross the service list with the location list. Every combination appears, including the ones nobody would have thought to include — which are frequently the ones with no competition.

Then cut it down hard

Four hundred and eighty thin pages is a liability, not a strategy. Check real search volume for each combination and keep only those with genuine demand. That typically leaves sixty to ninety worth building.

The judgement the tool cannot make

A page only deserves to exist if it can say something specific about that service in that place — a real address, real coverage, real examples. Where you cannot write anything specific, the page should not exist, whatever the volume data says. That is the line between a location strategy and a doorway page problem.

Try it: Cartesian Product (Keyword Combiner) on SeoWolf's Notepad.

Add Google Search Operator

What It Does

Search operators like site:, intitle: and inurl: turn an ordinary Google query into a precise question. Typing one in front of a single keyword is trivial. Typing it in front of four hundred is not.

What the operator actually changes

site:example.com restricts results to one domain. intitle: demands the phrase appear in the page title rather than anywhere on the page. inurl: looks only at the address. Each one narrows the result set in a different direction, and combining them narrows it further still.

Why prepending in bulk matters

A single operator query answers one question. A list of four hundred operator queries answers a survey question — which of these terms does this site actually have a titled page for? That is the difference between checking a hunch and mapping a site.

What you get back

A clean list of ready-to-run queries, one per line, that can be pasted straight into a search bar or fed into a rank tracker that accepts bulk input.

Bulk Search Operators Without Writing a Script

Prepending a fixed string to every line is the canonical one-liner. sed 's|^|site:example.com |' keywords.txt does it, and so does awk '{print "site:example.com " $0}'. Neither is hard to write. Both are easy to get subtly wrong.

The escaping problem

Search operators contain characters that shells and regex engines both care about. A domain in a sed substitution needs its delimiter chosen carefully — the | above exists because / would collide with a URL. Quote the wrong way and the shell expands something you did not intend before sed ever sees it.

The encoding problem after that

Operator queries usually end up in a URL. intitle:"exact phrase" needs its quotes percent-encoded; a + in a keyword is a space once it hits a query string. A script that builds the query correctly and encodes it incorrectly fails silently, returning plausible but wrong results.

When the browser tool wins

For a list you will paste once and discard, the script is more surface area than the task deserves. Reach for the shell when the step needs to run unattended on a schedule; reach for the browser when you need the output in the next thirty seconds.

In a Real Workflow: Auditing a Competitor's Topic Coverage in an Afternoon

You have been asked whether a competitor is genuinely stronger on a topic cluster or just louder about it. The honest answer needs data, and you have until the end of the day.

Turning a keyword list into a coverage map

Take the cluster's keyword list — say three hundred terms — and prepend site:competitor.com intitle: to every line. Each resulting query asks Google a specific question: does this competitor have a page whose title targets this term?

Reading the results

The pattern in the answers is the finding. Fifteen titled pages across three hundred terms means they own a handful of head terms and nothing else, and the long tail is genuinely open. Two hundred titled pages means they have systematically covered the cluster and you will need a different angle than volume.

Why this beats a tool subscription for this question

Third-party estimates of a competitor's coverage are modelled from sampled data. This asks the index directly. For a one-off strategic question, that directness is worth more than the dashboard.

Try it: Add Google Search Operator on SeoWolf's Notepad.

Hreflang Tag Generator

What It Does

Hreflang annotations tell search engines that several URLs are the same content in different languages or regions, and which one suits which audience.

What a tag contains

A language code, optionally a region code, and the URL of that version. en-gb is English for the United Kingdom; en alone is English generally.

Generating rather than typing

A site in six languages needs each page to reference all six versions, including itself. That is thirty-six annotations for six pages, and hand-writing them is how errors enter.

The rule that catches everyone

Annotations must be reciprocal. If page A points to page B, page B must point back to A, or the whole set is ignored.

Hreflang Fails Silently and Grows Quadratically

Hreflang is unusually unforgiving: a single malformed entry causes the entire cluster to be ignored, with no error anywhere.

The annotation count explodes

Each page must reference every version including itself, so n language versions produce n² annotations across the set. Ten locales over a thousand pages is a hundred thousand annotations. Generate them from data; do not template them by hand.

Codes are ISO, and the obvious guess is often wrong

Language is ISO 639-1, region is ISO 3166-1 alpha-2. The United Kingdom is gb, not uk. Japanese is ja, not jp. Chinese needs a script subtag — zh-Hans or zh-Hant — because simplified and traditional are not distinguished by region alone.

Absolute URLs and one canonical per version

Relative URLs are invalid here. Each annotated URL must also be self-canonical: if the German page canonicalises to the English one, you have told the engine both that they are alternatives and that one does not exist independently. That contradiction voids the cluster.

Always declare x-default

It catches every locale you did not enumerate. Without it, unmatched visitors get whichever version the engine guesses.

In a Real Workflow: Why Your German Customers Land on the English Page

An international site with proper translations still serves the wrong language version in search results. The translations are fine; the annotations connecting them are not.

The symptom

German searchers see the English page ranking for German queries. The German page exists, is indexed, and is not being chosen — because nothing tells the search engine the two are alternatives rather than competitors.

The commercial cost

A visitor landing in the wrong language usually leaves. Every one of those is a lost sale from a customer who searched for exactly what you sell, and the analytics report it as a bounce with no obvious cause.

Language and country are not the same

es covers Spanish everywhere. es-mx targets Mexico specifically. If pricing, currency or shipping differ by country, you need regional codes; if only the language differs, country codes fragment your signals for no benefit.

Try it: Hreflang Tag Generator on SeoWolf's Notepad.

Robots.txt Tester

What It Does

A robots.txt tester takes a set of rules and a URL and reports whether a crawler would be allowed to fetch it.

Why testing beats reading

robots.txt matching rules are less intuitive than they look. Which group applies to which crawler, how wildcards behave, and which of several conflicting rules wins are all easy to get wrong by inspection.

What blocking actually does

Disallow prevents crawling, not indexing. A blocked URL can still appear in results if other pages link to it — without a description, because the crawler was never allowed to read it.

The rule worth remembering

To keep a page out of the index, allow crawling and use a noindex directive. Blocking a page in robots.txt prevents the crawler from ever seeing that directive.

robots.txt Matching Rules Are Not What You Expect

The format looks simple and its matching semantics are genuinely surprising in several places.

Only one group applies

A crawler picks the single most specific matching User-agent group and ignores every other group entirely, including the wildcard one. Rules in User-agent: * do not apply to Googlebot if a User-agent: Googlebot group exists anywhere in the file — a very common misunderstanding that leaves intended rules silently inactive.

Longest match wins, not first

Where Allow and Disallow both match a URL, the rule with the longer path pattern wins regardless of order. Allow: /blog/public/ beats Disallow: /blog/ for a URL under the former.

Wildcards are limited

* matches any sequence and $ anchors the end. There is no character class, no alternation and no capture. Anything more expressive has to be handled elsewhere.

It is per-origin and per-port

https://example.com and http://example.com have separate robots.txt files, as does each subdomain and each non-standard port. A rule on one does not govern the others.

In a Real Workflow: The One-Line Mistake That Removes a Site From Search

Disallow: / in a live robots.txt blocks the entire site. It is a single line, it is trivially easy to deploy by accident, and it is the most damaging SEO error that exists.

How it happens

A staging environment carries a blanket disallow to keep it out of the index. Someone deploys the staging configuration to production. Nothing looks wrong — the site loads perfectly for visitors — and rankings begin disappearing within days.

Test before and after every deploy

Check a handful of important URLs against the live file after any release that touches server configuration. It takes a minute and catches the one error that can undo a year of work.

Monitor rather than remember

Set up an alert on the contents of the file. Relying on someone thinking to check is how this survives long enough to cost traffic — the damage compounds daily and recovery takes far longer than the outage did.

Try it: Robots.txt Tester on SeoWolf's Notepad.

The Bottom Line

Treat every measurement here as a guide, not a rule. Search engines truncate by pixel width rather than character count, rewrite snippets when they find better matches, and judge relevance by meaning rather than raw frequency. The tools tell you where to look; your judgement decides what to change.

Next step: All of these tools are free in SeoWolf's Notepad — paste a list and transform it in your browser.