The Characteristics of a Machine Learning Problem: A Task, Data and Solution Framework for SEOs

The single most useful machine learning skill I teach SEOs is not writing code. It is knowing whether a task is even a machine learning problem before you sink a week of your life into it. That judgement, honestly, is what separates people who quietly automate half their workload from people who burn out trying to build a neural network for a job a spreadsheet formula could have done.

Whenever I start any machine learning project, I ask three questions. What is the task I am trying to perform? What is the data I have to work with? And what does the solution actually need to look like to be useful? Get those three characteristics right and you will pick the correct tool almost every time, or, just as valuable, you will correctly decide that machine learning is the wrong tool and save yourself the trouble.

Here is the part that makes this more than a beginner exercise. The exact same three characteristics explain a lot about the AI search systems you are already competing inside. They explain why Google often cannot tell a creator why their traffic dropped, and why ChatGPT hands you a slightly different answer every single time you ask it the same question. So let’s build the framework, and I promise it will change how you look at both your own automations and the black boxes ranking your content.

Start with the real first question: is this even a machine learning problem?

You do not need to become a machine learning engineer. You need to become a marketer who can spot an automatable task and match it to the right approach. That is a completely different, and much more achievable, goal.

There is a saying I picked up from Noah Lerner that I think about constantly: build painkillers, not vitamins. When you are learning, the temptation is to reach for the most impressive-sounding solution, a custom model, an AI agent, a fine-tuned transformer, because it sounds fancy and earns you social points. Resist it. The best first automation is the one that removes a genuine, recurring pain in your workflow, no matter how unglamorous the method. Confidence compounds. Ego points do not.

So before anything else, walk a task through the three lenses below. If it survives all three, you have a machine learning candidate. If it does not, that is not a failure. That is you saving your own time.

Task characteristics: what are you actually asking the model to do?

At its core, every machine learning task is either supervised or unsupervised, and each of those splits into a handful of sub-tasks. The dividing line is beautifully simple: do you have labelled data, meaning do you already know the correct answer for at least a subset of your data?

Supervised learning needs labelled data. You already know the right output for some of your examples, you train the model on those, and then you let it predict the rest. Unsupervised learning works on unlabelled data. You do not have the answers, so the goal is to let the model surface hidden patterns and structure that you then interpret yourself.

This is a deliberately simplified view, by the way. In reality supervised learning branches into tree-based models and linear models, unsupervised branches into clustering and association, and each of those has its own family of algorithms with different strengths. You do not need all of that on day one. You need to know which of the four boxes above your task lives in.

Beyond the basics: deep learning and reinforcement learning

Two terms you will bump into a lot are worth defining, because knowing when they apply is mostly about knowing when they do not.

Reinforcement learning is a flavour of unsupervised learning where a model learns through trial and error, optimising its own performance over many attempts. Think of a Boston Dynamics robot falling over a million times until, on attempt one-million-and-one, it works out the exact sequence of movements to stand up. Powerful, and almost never what you need for a marketing automation.

Deep learning uses deep neural networks and can power both supervised and unsupervised tasks. It excels at image recognition and natural language processing, but it demands large datasets and serious computing resources. It is also, as we will see in a moment, notoriously hard to explain. As a beginner, you will very rarely reach for it, and that is completely fine.

A shortcut for spotting the right category

The clearest map I have found for navigating all of this is a flowchart from the brilliant Karen Hao, which walks the whole field of AI as a series of yes or no questions. Is it finding patterns in large amounts of data? Then it is machine learning. Is it being told what to look for? Then it is supervised. Does it involve deep neural networks? Then it is deep learning. Is it reaching a goal through trial and error? Then it is reinforcement learning. It is worth keeping open. You can find it in her piece “What is machine learning?” for MIT Technology Review.

Key considerations when choosing a task

The nature of the problem is only the start. Before you commit, run through these too:

Outcome validation. Do you have labelled data to check the model against? Yes points you to supervised methods. No points you to exploratory, unsupervised ones.

Complexity and resources. Simple tasks like basic classification can be handled with straightforward, pre-built models. Complex tasks like image recognition pull you toward deep learning and the hardware bill that comes with it.

Skill level. Start with tasks you can do using pre-trained models and friendly libraries. Save neural networks and reinforcement learning for when you have the data and the confidence to match.

Repeatability. Is this a one-off analysis or something that needs to run in production every day? A one-time automation is far more forgiving than a system other people will depend on.

Real-world feasibility. Do you genuinely have the data, the time and the resources? Most people who dream about building a custom model do not have the labelled data it would require. Be honest with yourself here, early.

Data characteristics: what are you feeding the model?

Data in, data out. The type of data you hold shapes everything downstream, the task you can run, the algorithm you can use, even which API is available to you. If you do not understand your data’s format and limitations, matching it to the right method is mostly guesswork.

Most of the data you will meet in SEO falls into six types. Here is what each one looks like and where it shows up in our world.

Notice how many of these you can already access. Google Analytics and Search Console hand you numeric and time-series data on a plate. Others take more effort: user reviews might need a scraper, call transcripts might mean collaborating with your support team, video needs its own extraction step. Knowing the source is half the battle.

Four questions to ask about your data

What format is it in? Numeric, textual, image, time-series, audio or video. This alone narrows your options fast.

Is it labelled or unlabelled? Do you know the expected outcome for at least a subset? This is the fork in the road between supervised and unsupervised, so it is worth answering carefully.

What is the scale? A few hundred rows or a few million? Scale drives your costs, your techniques and the skills you will need. It is the difference between a Google Sheet and a distributed pipeline.

Is it clean? Missing values, duplicates and inconsistencies will quietly wreck your results, especially if you are self-training a model. Clean data is not glamorous, but it is where most of the real work lives.

Solution characteristics: is ML actually the right tool, and which kind?

You have a task and you understand your data. Now the honest question: should you use machine learning at all, and if so, what kind of model? This is where I run every idea through a quick four-question gut-check that has saved me from a lot of bad projects.

The four-question ML gut-check

1. Is the task mission-critical? If it is unacceptable for the method to occasionally fail, and it will occasionally fail, in ways you do not expect, then do not rely on machine learning. If someone’s job or a real business outcome hinges on this being right 100% of the time, walk away and find a fail-proof method. Seriously.

2. Must the results be consistent every time? Machine learning, and especially generative and unsupervised methods, will often give you a slightly different output on each run, even with identical input. If you write a meta description with an LLM three times you will get three correct but different descriptions. If your task truly needs identical output every time, ML is the wrong fit.

3. Must the results be explainable to a stakeholder? If you need to tell a client exactly why the system reached a decision, skip deep learning. The calculations inside a deep model are extremely hard to deconstruct into a story a human can follow.

4. Is “better than average” good enough? If it is acceptable that, on average, the model beats your current method, on accuracy, on consistency, or simply on time saved, then congratulations, you have a real machine learning candidate. Go take a look at your options.

Keep this checklist in your back pocket and run it every time you wonder whether to automate something.

Pre-trained, self-trained or fine-tuned?

Say you have decided ML fits. The next decision is where your model comes from. There are three options, and for most marketers the answer is almost always the first one.

Here is the thing to internalise: you are not training to become a machine learning engineer. You are training to become a marketer who works more efficiently. As a beginner, pre-trained models from the big providers or from Hugging Face will give you the best return on your time, every time. You can always graduate to fine-tuning later.

A quick word on training, testing and validation data

If you ever do go down the self-training route, you will split your labelled data into three parts. You do not need to memorise this, but knowing the vocabulary helps you talk to stakeholders and developers.

Data split	Purpose
Training data	Teaches the model how to perform the task, for example a labelled set of posts tagged Product Reviews, How-To and News
Testing data	A separate set the model has never seen, used to check how well it generalises. You hold the labels; the model only sees the text
Validation data	Held back during training to tune settings and avoid overfitting to the training set

If you do not have enough data to fill all three buckets, that is your signal to use a pre-trained or fine-tuned model instead. No shame in it.

Do not forget bias

Machine learning models can be biased, meaning they favour some outcomes and quietly exclude others. We have seen job adverts shown mostly to users a platform identified as male, and facial recognition that performs worse on certain skin tones. When you train from scratch, use large and representative datasets and deliberately include a range of backgrounds and cases. When you use a pre-trained model, you can steer it with careful prompting that includes counter-examples. Bias is not a footnote. It is part of doing this responsibly.

The scorecard I actually use

When I am deciding whether a machine learning solution justifies the effort, I do not rely on gut feeling. I score it against a spread of factors and look at the bottom line as a whole.

Factor	The question to ask
Insights	Does the solution produce genuinely actionable insight?
Complexity	How hard is it to build, and to interpret the results?
Scalability	Can it scale across more pages, more clients, bigger data?
Resources	Do you have the tools, expertise and team to run it?
Time efficiency	Does it beat the manual process on time?
Accuracy	Are the results reliable enough for who will see them?
Assets	Do you have the datasets and infrastructure required?
Bottom line	Does the payoff justify the time and resources spent?

Run a few tasks through this and a pattern emerges quickly. Some tasks are a clear fit for machine learning and others simply are not. Both answers are useful.

Putting it together: a worked example

Let’s take a task every SEO knows, writing meta descriptions, and walk it through all three characteristics.

Data characteristics: the input is textual, specifically your page content. Easy to access.

Task characteristics: this is a transformation task, turning page content into a summary under 160 characters, and it can also be generative if you want them written from scratch. No labels required, so it sits on the unsupervised side.

Solution characteristics: is it mission-critical? No. Are different results each time acceptable? Yes, any accurate summary will do. Do you need to explain the process? Not really. Does it beat the current method? Absolutely, it gets you to a good-enough draft far faster than writing each one by hand.

Four green lights. This is a textbook machine learning automation, and a perfect first project. Now run the same three lenses over “forecast next year’s revenue for a board presentation” and watch how fast the mission-critical and consistency questions turn red. That contrast is the whole skill.

The AI search connection

Here is why this framework matters more than ever. The systems deciding whether your content gets surfaced, Google’s ranking stack, AI Overviews, ChatGPT, Perplexity, Gemini, are themselves built on exactly the characteristics we just covered.

When Google held a creator event after the helpful content update, creators asked engineers to explain precisely why their content had stopped ranking. The engineers could not articulate it. That is not evasiveness, it is the explainability problem in action. Google’s ranking system leans heavily on deep learning, and deep learning trades away the ability to give a clean, step-by-step reason for its decisions. The system knows there is a failure point; it cannot always point to where.

The consistency question explains the other thing you have noticed. Ask an LLM the same question twice and you get two different answers, because generative models are probabilistic by design. That is why measuring your visibility inside AI search means sampling many responses rather than trusting a single check, and why “I appeared in ChatGPT once” is not the same as “I reliably appear in ChatGPT.”

Once you can see the task, the data and the solution characteristics behind a system, it stops being a black box and starts being a set of trade-offs you can reason about. That is a genuine competitive advantage in AI search.

Where this goes next

This post covers the framework I use to decide whether a task is a machine learning problem and, if it is, what kind of model to reach for. The full walkthrough, with the complete decision flowcharts, the bias-reduction techniques, and hands-on examples of running these judgements across real SEO workflows, is inside Introduction to Machine Learning for SEO, in the Machine Learning Basics module.

If you want to start applying it today, grab the free ML Data Characteristics guide and, once you are ready to pressure-test an idea, the When to Use Machine Learning in SEO decision checklist. Then read the companion post on how to find ML-enabled automation in your own SEO workflow, which turns this framework into a repeatable way to search for opportunities.

Related glossary terms

• Supervised learning
• Unsupervised learning
• Dimensionality reduction
• Deep learning
• Reinforcement learning