Most bad conference sessions fail in the preparation phase, not on stage. By the time a speaker is at a podium, the fundamental structure and content choices have already been made, and there is not much a good delivery can do to rescue a poorly built session. I have watched enough conferences from both sides to believe that. Here is how I actually build a talk.

Step One: Understand the Audience Before Touching the Content

The first thing I ask an organizer is not about logistics — it is about who will be in the room. How much do they already know? What do they do day-to-day? What are they hoping to leave with? What topics are other speakers covering so I do not repeat them?

Those questions shape everything that comes after. An audience of agency owners who have been running SEO for a decade needs a different session than a mixed audience of marketing managers at mid-size companies. Same topic, completely different angle, different depth, different examples.

If an organizer cannot answer those questions, I will usually help them think through it. But I need some version of those answers before I start building. I have turned down or rebuilt sessions because the answers did not add up — an organizer once described the audience as ‘beginners to intermediate’ and then, once I asked more, described a room full of in-house SEO leads who had been doing this for years. The label organizers reach for and the actual room in front of them are not always the same thing, so I keep asking until the picture is specific enough to build from.

Step Two: Pick One Problem, Not a Survey

The worst sessions try to cover the entire landscape of a topic in 45 minutes. SEO is a broad field. If I tried to cover everything in a single talk, I would give a shallow overview that leaves the audience with a general sense that SEO is complicated. That is not useful.

Instead, I pick one specific problem the audience is likely dealing with and go deep enough to be genuinely useful on it. The audience leaves with a clear understanding of that one thing and something they can do about it. That is a better outcome than a broad tour.

Choosing that one problem is its own skill. I look for something that is commonly misunderstood rather than commonly unknown — a topic where the audience has some exposure but the mental model most of them are carrying around is subtly wrong. Correcting a wrong model is more valuable to an experienced room than introducing something they have never heard of, because it changes decisions they are already making, not just decisions they might make someday.

Step Three: Structure for Action, Not Information

Information is not the same as utility. A session can be full of true, accurate, interesting information and still leave the audience with nothing to do with it. I build toward action from the start.

The structure I use most often:

  • Open with a problem the audience recognizes — something they have likely encountered or worried about
  • Explain why the standard approaches fail or are incomplete
  • Walk through how I think about the problem differently, with real examples
  • Give three to five specific things they can do the following week
  • Close by connecting those actions back to the larger picture

That arc works because it respects that people came to a session to improve their situation, not just to hear someone talk about a subject.

The number of action items matters more than it sounds like it should. Give an audience one action item and it feels thin. Give them fifteen and none of them will remember any of them by the time they are back at their desk. Three to five is the range where people actually retain and attempt the advice — I have tested this by asking audiences a few weeks later what they actually implemented, and sessions with a tight action list consistently outperform sessions with a long one.

Step Four: Use Real Examples, Not Hypotheticals

Teaching through SEO University has reinforced something I already believed: people learn through examples, not principles. I can explain schema markup as an abstract technical concept or I can walk through what a JSON-LD block looks like for a specific page type and why each field matters. The second approach actually transfers.

The examples I use come from real work done through Salterra Digital Services. I do not invent case studies or use sanitized hypotheticals that have been genericized into uselessness. Real examples have texture and specificity that abstract ones lack.

There is a discipline to this that is easy to skip under time pressure: a real example needs enough context to make sense to someone who was not there for the original project. I have sat through talks where the speaker references ‘a client we worked with’ and shows a screenshot with no explanation of the starting conditions, so the audience cannot tell if the result is actually impressive. When I use an example from Salterra work, I give the starting state, the specific change made, and the outcome — enough that someone could evaluate whether the same move would apply to their own situation.

Step Five: Test the Session Before the Stage

I run the material before I present it. Not always in a full dress rehearsal format, but at minimum I work through the sequence out loud to find places where the logic skips or the transition is abrupt. A talk that reads well in an outline can fall apart in delivery if the structure does not actually connect from section to section.

For complex technical content — structured data, AI search mechanics, audit methodology — I pay special attention to the moments where I am asking the audience to follow a chain of reasoning. If there is a gap in the chain, I need to find it before the session, not during it.

I also time it out loud at the pace I would actually speak — not read silently, which always runs faster than spoken delivery and leads to sessions that either rush the ending or get cut off before the close. A session that runs five minutes over on a rehearsal read is often fifteen minutes over delivered live, once you account for audience reactions, questions that come mid-session, and the natural slowdown that happens when you are actually explaining something rather than reciting it.

Step Six: Prepare for Q&A as Part of the Talk, Not an Afterthought

Q&A is where a lot of technical credibility is actually established or lost. I go into a session having already thought through the three or four questions I am most likely to get, given the audience and topic — usually some version of ‘how does this apply to my specific situation’ or a pushback on a claim I made. Having a real answer ready, rather than improvising for the first time in front of the room, is part of preparation, not something separate from it.

I also decide ahead of time how I will handle a question that is really a different topic in disguise — something that would take fifteen minutes to answer properly. Redirecting that person to talk afterward, rather than trying to answer it in thirty seconds and shortchanging both the question and the rest of the room’s time, is a judgment call worth making in advance rather than live.

For Organizers

If you are booking me for an event, the prep process I described above is what you can expect. I will ask you questions before I agree to the engagement. That is not me being difficult — it is how I make sure the session is worth your attendees’ time, and how I avoid showing up with a generic talk that could have been given to any room on any day.

For a look at how different formats serve different preparation needs, the keynote vs. workshop page is worth reading. For the full picture on working with me as a speaker, the main SEO speaker page is the starting point.