My mother has asked me what I do for a living several times. At one point, it became almost an annual tradition.
She’d ask. I’d try to explain SEO. Within a minute or two, she’d look confused, hold her head, and stop listening.
My mother is smart, by the way. I feel I need to make that clear. She just doesn’t spend her days talking about crawling, indexing, snippets, schema markup, search intent, internal links, and the other perfectly normal words SEOs use without thinking.
To her, it was all Greek.
Which is slightly funnier when you and your mother are actually Greek.
People often say that if you can’t explain something to a six-year-old, you don’t understand it well enough yourself.
I thought explaining it to my mom might actually be harder.
Six-year-olds grew up around computers. 😅
In March 2022, I turned this situation into a presentation called “How to Explain SEO to Your Mom” for the SEO Mastery Summit, hosted by Mads Singers.
When I gave that talk, I thought I was mainly talking about client communication. Looking back, I can see I was also talking about knowledge transfer.
Knowing how to do complex work and knowing how to transfer your understanding of that work are different skills. You can be an excellent SEO and still leave a client with no idea what matters, what to approve, or what to do next.
Clear explanation isn’t an optional extra added after the “real” work. It is part of the work.
Your mom and your client have more in common than you think
One of the original slides simply said:
Your mom = your customer.
Your client may know much more about marketing than my mother does. Others know that they want more visibility on Google and not much beyond that.
The similarity isn’t intelligence. It is missing context.
When you work with SEO every day, you forget how much knowledge sits behind ordinary-sounding terms. Even “organic result” assumes that the other person understands the difference between paid and unpaid listings. “Indexing” assumes they know Google doesn’t instantly know about every page on the internet. “Search intent” sounds obvious until two people mean completely different things by it.
Experts carry a lot of invisible context. Then we speak as if everyone else can see it too.
Take a technically correct definition of SEO. It may talk about improving the quality and quantity of traffic, positioning pages in organic results, or optimizing a site’s presence in search.
Clear enough for an SEO.
For my mother? Not really.
She knows Google. She knows that she searches for something, sees results, and clicks one. That’s where I need to start.
But before I decide how to explain something, there’s another question I need to answer first:
What do they actually need to understand?
Before deciding what to explain, ask a better question:
What does this person need to do with the information?
- My mother only needs enough context to understand what I do for a living.
- A business owner may need to decide whether an issue is worth paying to fix.
- A marketing manager may need to understand how the recommendation affects content, campaigns, reporting, and other priorities.
- A developer may need acceptance criteria, technical details, dependencies, and a way to confirm that the fix worked.
- A new SEO employee needs more again. They need the reasoning, examples, common exceptions, and enough practice to make a similar judgment without me standing beside them.
Same subject. Different depth.
A good explanation gives someone the amount of complexity required to perform their role, make a good decision, or take the correct next action.
Does my client need to understand every part of technical SEO?
No.
Do they need to understand why I’m recommending development work, what could happen if they ignore it, and why it comes before another task?
Yes.
Once I know what they need to understand, I can decide what to explain first. And most of the time, I don’t start with what something is. I start with why they should care.
Focus on why
This was the main point of the original presentation, and I still agree with it.
If you tell a business owner that their canonical tags are inconsistent, their first question probably isn’t, “Could you explain the HTML?”
They want to know:
- Why does this need fixing?
- What happens if we leave it alone?
- Why should the business spend time or money on it?
The definition matters only as far as it helps answer those questions.
So, what is SEO?
I would explain it like this today:
SEO is the work you do to help the right people find your website when they’re searching for something you can help them with, and to make sure they have a useful experience once they arrive.
Is that a complete definition?
No. SEO also involves crawling, indexing, content, links, local search, measurement, and a long list of other things.
But completeness isn’t the purpose of the first explanation. Orientation is.
You can add detail after someone has a simple mental model to attach it to. Starting with everything usually means they retain nothing.
This is also the difference between simple and simplistic.
- A simple explanation removes detail that the listener doesn’t need yet.
- A simplistic explanation removes nuance that could change the decision.
Responsible simplification requires expertise. You need to know which details are optional, which are essential, and which become important only in a specific situation.
And sometimes, no matter how simple the words are, showing the thing is still much easier than explaining it.
Show, don’t just tell
One of my favorite parts of an SEO audit is still recording the client walkthrough. I’ve done this for years.
I would open the client’s actual website, show the issue, explain why it mattered, and then show an example of a better version. Clients often told me that those recordings made the audit easy to understand.
That worked far better than another page of definitions.
If the navigation is confusing, show the route a visitor has to take. If a search result makes a weak first impression, place it beside a clearer one. If the heading structure is messy, open the page and point to what the reader sees. If the site is painfully slow, a client can usually understand the problem before PageSpeed Insights finishes loading.
Use whatever makes the difference visible:
- a screenshot with one issue highlighted
- a short screen recording
- a before-and-after example
- a diagram showing how pages connect
- a real search result
- a demonstration on the client’s own site
Showing is useful, but it still isn’t enough if the explanation has nowhere to go.
For every meaningful recommendation, the person should be able to answer:
- What is happening?
- Why does it matter?
- What happens if we ignore it?
- What should we do?
- Who needs to do it?
- How important is it compared with everything else?
Technically correct? Maybe.
Useful? Not necessarily.
If the client receives 87 findings with no ownership, priority, or next action, they technically have the information. They don’t have a usable plan.
So what does that actually look like in practice? Let’s go back to some of the terms that made my mother’s head hurt in the first place.
Okay, so how would I actually explain all this?
The original talk included many terms I regularly had to explain in audits. These examples still show the method.
Robots.txt and XML sitemaps
I used to describe robots.txt as a file where you tell Google’s robots what they can and cannot do on your site. That is close, but it needs one important clarification.
A robots.txt file gives compliant search-engine crawlers instructions about which URLs they may request. It mainly concerns crawling. It is not the right mechanism for reliably keeping a web page out of Google’s index, because Google can sometimes discover and index a URL without crawling its content.
What would I say to a business owner?
“This file gives search engines directions about where their crawlers should and shouldn’t go. We need to check that we aren’t accidentally blocking an important part of the site.”
An XML sitemap is the map. It lists the URLs you consider important and can help search engines discover and understand them.
But a page missing from the sitemap isn’t automatically invisible, just as putting a page in the sitemap doesn’t guarantee that Google will crawl or index it. Internal links and other discovery routes still matter.
Does your client need a lesson on XML syntax?
Probably not.
They need to know whether important pages are easy to find and whether we’re sending conflicting directions.
Titles, snippets, keywords, and search intent
Your result in Google is often a potential customer’s first impression of the business. In the original talk, I called it your free ad. I still like that explanation, with one caveat: you can influence the title link and description people see, but you don’t completely control them.
Google may generate a different title link from information on the page, and snippets are often created from the page content to match a particular search.
So I would say:
“We want each page to make it immediately clear what it offers and why it is relevant. We will write a useful title and description, but we also need the page itself to support that promise.”
Keyword research is partly about algorithms, yes. It is also about learning the language customers actually use. A company may call something a “workforce capability solution” while its customers search for “how to train new agency employees faster.” If the website speaks only the company’s language, people may not recognize that the page is for them.
Then comes search intent. What is the person trying to do? Learn? Compare options? Find a local provider? Buy something now?
Using the right phrase on the wrong kind of page doesn’t solve much. The content and the next action have to match the reason behind the search.
Image alt text
I still explain alt text as an invisible caption, although it is more accurately a text alternative for an image.
Its first job is accessibility. A screen reader can use appropriate alt text to communicate the purpose or content of an image to someone who cannot see it. Search engines can also use that text, together with the page around it, to understand the image.
Reducing alt text to “another field where we put a keyword” is how you get descriptions that are awkward for everyone.
And no, not every image needs a written description. Decorative images should generally have empty alt attributes so assistive technology can ignore them. The useful question is not “How many images are missing keywords?” It is “Which images carry meaning, and is that meaning available to someone who cannot see them?”
Structured data and schema
Humans can look at a recipe and recognize the name, ingredients, cooking time, instructions, and reviews. A machine benefits from those parts being labeled in a consistent, machine-readable format.
That is the simplest way I know to explain structured data.
For a business owner:
“We add labels behind the page that help search engines identify specific information, such as this being a recipe, this number being the cooking time, and this value being a review rating.”
Valid structured data can make a page eligible for richer search appearances. It doesn’t guarantee a rich result.
A developer needs the supported type, required properties, validation results, and implementation details. The client may only need to see a real example and understand whether the opportunity is relevant to their pages.
Site structure, navigation, headings, and internal links
A website is like a book.
The pages are chapters. The navigation is the table of contents. Headings give each chapter a clear structure. Internal links guide readers to related or supporting chapters.
Then show them their site.
Can a visitor predict where a service will be? Are important pages buried? Does the heading structure help someone scan the page? When the article mentions a relevant service or guide, is there a useful link to it?
Most clients don’t need to see what an H1 looks like in HTML. They need to recognize a page that is easy to navigate and understand. A developer or SEO implementing the recommendation may need the technical rules as well.
404 pages and redirects
If a shop moves, it puts a sign on the old door telling people where to go. A redirect does something similar for a URL.
If a page has moved or there is a genuinely relevant replacement, redirect the old URL to the new one. Don’t send every removed page to the homepage just to avoid a 404. That is like closing a shoe shop and directing everyone to a random supermarket.
Sometimes a page is simply gone and there is no suitable replacement. A legitimate 404 is acceptable. The useful question is what the visitor sees next.
Can they search? Return to a helpful category? Find a current alternative? A thoughtful 404 page doesn’t pretend the missing page exists. It helps the person recover.
Site speed and Core Web Vitals
Waiting for a slow website feels like Monday-morning traffic. Nobody enjoys it, and plenty of people will choose another route.
That is enough to explain why speed matters.
The current Core Web Vitals are:
- Largest Contentful Paint (LCP), which looks at loading performance
- Interaction to Next Paint (INP), which looks at responsiveness
- Cumulative Layout Shift (CLS), which looks at visual stability
Does the business owner need to memorize those?
Please, no.
They need to understand what visitors are experiencing, which pages or templates have a problem, how serious it is, and what kind of work may be required. A developer needs the measurements and diagnostic detail. Again, the depth follows the role.
Backlinks, authority, and E-E-A-T
Backlinks are often explained as votes of confidence. If a respected industry publication links to a useful guide on your site, that link can help people and search engines see the page as a credible resource.
But “more votes” is too simple. Relevance, editorial judgment, the reputation of the source, the context of the link, and whether anyone genuinely finds it useful all matter. I would no longer give a client an arbitrary Domain Authority threshold and tell them every link above it is good.
I would say:
“We want your business and content to be useful and credible enough that relevant people choose to mention, recommend, and link to it. One real recommendation from the right place can be worth far more than hundreds of links created only to manipulate a metric.”
Then there is E-E-A-T: experience, expertise, authoritativeness, and trustworthiness.
No, it still has nothing to do with food. I can hear my mother making that joke even now. 😂
I treat E-E-A-T as a useful lens. Do readers have good reasons to trust this content and its source? Is it clear who created it? Does the person have relevant experience or expertise? Are claims supported? Is the business transparent? Does its wider reputation support what it says about itself?
E-E-A-T isn’t a specific ranking factor, and there is no single E-E-A-T score to chase. Trust is built through the content, the people behind it, the site’s policies and evidence, and what reputable sources say elsewhere.
Most of those explanations still work pretty well. But if I gave the presentation again today, I’d change more than a few SEO definitions.
What I would change if I gave this talk today
Some updates are obvious. E-A-T became E-E-A-T. Interaction to Next Paint replaced First Input Delay. I would be more precise about crawling versus indexing, and careful about implying that site owners control exactly what Google displays.
The bigger changes are about communication.
I would:
- spend less time on arbitrary scores and old click percentages
- talk more about search intent and the person behind the query
- distinguish more clearly between a founder, marketer, developer, and junior SEO
- make accessibility part of the explanation from the beginning
- add priority, ownership, and implementation context to every recommendation
- explain the judgment behind the recommendation, especially when the answer depends on the situation
I would still use my mother as the test audience.
Not because every explanation should be reduced to beginner level. Because she exposes every assumption. If I cannot explain why something matters without hiding behind vocabulary, I may know the term without having thought hard enough about the decision.
And probably the biggest change would be this: I’d spend less time trying to teach the client SEO.
Your client doesn’t need an SEO lesson. They need to make a good decision.
An audit is not better because it contains more findings. I have seen reports that are technically impressive and practically exhausting, with enough red and orange cells to make the website look as if it may collapse by Thursday.
But the client still doesn’t know:
- what matters
- what comes first
- what can wait
- who owns each action
- how much effort it may require
- what success should look like
That isn’t just a communication problem. It is a deliverable problem.
The client hired your ability to detect issues. They also hired your judgment.
For the next audit or recommendation you present, try this:
- Lead with the business or user consequence.
- Show the issue on the real site.
- Explain only the technical detail required for the decision or implementation.
- Give a clear next action and owner.
- Place it in context: now, later, monitor, or intentionally leave alone.
That last option matters too. Expertise includes knowing when a technically imperfect thing does not deserve the team’s attention yet.
And once you get used to explaining the work this way to clients, you start noticing the exact same problem when you have to teach the work to someone else.
The same problem shows up when you have to train someone
Eventually, if you stay in SEO long enough, you may have to explain the work to someone who isn’t a client at all.
Maybe you’re training a junior SEO. Maybe you’re onboarding someone new. Maybe you’re reviewing someone else’s audit, writing a process, or trying to document how you make a decision so another person can make it next time.
And suddenly, you’re dealing with the same problem again.
Giving someone the information doesn’t mean you’ve transferred the knowledge.
Give a client a jargon-heavy audit and they may have the information without the understanding needed to act.
Give a junior SEO a folder containing 200 procedures and the same thing can happen. The documentation exists. The knowledge has not necessarily transferred.
Procedures often capture the visible steps while leaving out:
- why the process exists
- when to use it
- what changes in a different situation
- examples of good and weak work
- common exceptions
- the signals an experienced person notices
- when to stop and ask for help
That’s actually where I started seeing the connection between the way I’d been explaining SEO to clients for years and the work I now do around onboarding, learning, documentation, and knowledge transfer.
The lesson isn’t that every SOP needs to become a textbook. A checklist may be perfect for an experienced SEO doing a familiar task. A junior making judgment-heavy decisions needs context, examples, feedback, and practice.
Good knowledge transfer reduces dependence on the original expert. The client can make the decision. The developer can implement the fix. The junior can handle the next similar case and know when it is different enough to ask.
That is when information becomes usable capability.
Of course, even after you’ve explained everything beautifully, people will still have questions. Some questions apparently survive every SEO presentation ever made.
A few questions my mom, or a client, would still ask
Why don’t I see SEO results yet?
Because SEO is cumulative, competitive, and ongoing. Search engines need to discover and reassess changes. Competitors keep working. The speed and size of the result depend on the site, market, starting position, resources, and execution.
That doesn’t mean “wait forever and trust the process.” Agree on leading indicators, check whether the work was implemented correctly, and review whether the strategy is producing movement.
Why did my visibility drop?
It could be a site change, technical problem, competitor improvement, change in demand, search-result change, algorithm update, loss of links, or a combination of several things.
“We didn’t change anything” doesn’t mean the environment stayed still.
The right answer starts with investigation, not a favorite theory.
Why don’t I rank for my brand name?
If the brand name is generic or shared by several businesses, Google may have difficulty understanding which entity the searcher wants. New businesses may also have a limited online presence, inconsistent information, or technical issues affecting discovery.
Check the technical basics, strengthen consistent brand signals, build a credible presence across relevant platforms, and make the site clearly represent the business. Sometimes the name itself simply creates a harder search problem.
Do I really need to understand all of this?
No.
You need to understand enough to make the decision that’s yours to make, know what happens next, and know when you need to bring someone else in.
You don’t need to become an SEO.
Thankfully.
Good for now. Please no more.
Before giving the original presentation, I tested it on my mother.
Her final reaction was roughly:
“Good for now. Please no more.”
I consider that a success.
The goal was never to turn my mother into an SEO expert. It isn’t to turn every client into one either.
The goal is to make expertise usable by someone who doesn’t share it.
That person may be a client deciding whether to fund a recommendation, a developer implementing it, a junior SEO you’re training, a new employee you’re onboarding, or my mother finally having a reasonable answer when someone asks what her daughter does for a living.