Who’s using LLMs to build stuff? Be honest. What about Claude Code? Who feels like they’re fighting with it all the time versus getting work done? This is for you. Okay. So I was only six years old.

It was probably June seventeenth nineteen eighty. I was playing with a whole bunch of kids.

I was chasing a kid through a house. There was a door. It had two locks. I kicked the door. Boom.

Boom. And I missed the wood, and I kicked through the glass, and I cut my leg wide open. I almost died. I almost bled out.

They took me to a hospital in Jerusalem. I was lying there awake the whole time they were doing surgery, stitching up my leg. I’ll never forget looking at the entire operation happening on the doctor’s glasses.

Eight inches. That’s how big the scar was in my mind.

I’m a marketer, right? We always blow things out. I just measured it the only day the other day and it’s five inches.

Things change.

We never forget our scars, right?

That is what this talk is about. It is about my exploration building things with Claude Code over the last year. It has been a lot of pain.

There’s been a lot of successes.

And trying to figure out why or how you guys can incorporate it into your workflows, I asked a whole bunch of other SEOs, and they had a lot of good reasons for why I should deliver this talk and why it mattered for them.

So I’ll just go through a couple of them for you. I love this one. When we build these tools, it allows us to get out of the kind of meaningless workflows and really focus on strategy. I love this from the product side, from my pal Brad Porter.

He is the bomb.

As a product person, it allows how many of you guys are building proof of concepts if you are an SEO product manager? Right? Like, you have to be doing this stuff to deliver value for your teams.

The thing that I think most of us forget is that we have crazy deep domain expertise around SEO, and when we think about how anyone can build anything and software is cheap, they do not understand all the data like we do. And so that’s what is gonna be the through line with the stuff that I talk about, which is that I’ve been able to leverage this crazy domain expertise to build stuff that blows me away in relation to anything I’ve been able to build in the past.

When I think about what some of these power moves are, when I work with Claude Code, a lot of it is doing the research and letting Claude go off with a whole bunch of sub agents to help me understand an entire new problem domain that I’ve never touched before. And we’ll get into that.

When I work, a lot of times I’m demanding elegance out of the tool. If you’re going to write down a couple words from my deck, elegant is the word.

When you’re when you’re asking it to build things, you want to demand that all the time. Another power move that I think most people have a hard time with is change. Right?

I use a couple of tools inside of Cloud Code that allow me to do self reflection all the time with a weekly cadence to figure out how I can work better. And then I incorporate those changes into how I actually work. So I definitely want to share that with you. If you’ve seen me talk before, you’ve probably seen this slide, maybe with a different font. I try and include it every single time because I think it’s the most important thing that we can do when we’re trying to solve problems with products.

Focus on building painkillers.

It’s not about vitamins. It’s not about doing data analysis and sitting there and cross filtering stuff. It’s about solving real problems that are tied to business goals.

And that brings us to this crazy thing that I’ve been working on over the past sixty days or so called SEO Loop. And it started with a webinar that I did for AirOps in early March. They asked me to build an MCP around Search Console data, and I did it. And we did it in a live webinar and had fun and stuff.

And then I walked away from that feeling like, man, that thing sucked. Like, I don’t really like an MCP. I really want to interact with the data. And I built a tool a while ago that was a vitamin.

It was called Branch Explorer. It allowed me to look at Search Console data at scale, which was really, really fast because it was powered by BigQuery. But didn’t really get product market fit for a bunch of reasons. Number one, horrible onboarding flow.

It took about an hour to get onboarded in the system. It was really difficult to set up query groups to allow you to classify your data. It’s a pain in the ass to set up URL patterns. And so, it also wasn’t tied to revenue at all.

And so when I started thinking about this, SEO loop, and this is really difficult tension for me because I built a product and I’m showing you a product, but I don’t want it to be really salesy. I really want it to be like me sharing the thoughts that went through how to build something and how you can take those thoughts and use them too. So just please hear me from that perspective when I’m going into this stuff.

One of the things that I hated about search data was that it was never tied in a concrete way to business goals, which for me is money.

And so I wanted to think about how do we turn search volume into revenue?

And so that was one of the key things that I wanted to solve. And it was a pretty simple formula, and you guys can write this down and steal it, but it’s like search volume and it’s times by your website’s live CTR, by an average order value, or lifetime value, however you like to calculate value, times the conversion rate, times the lead to close rate.

Can we get behind that as a formula? Does it make sense? That’s how I thought about it. Right?

So I wanted to be able to structure information for someone who needs to make a strategic decision based on who the personas were in their site from Search Console data, and where they are in the journey stage. Because I thought that that would be really useful. And this all started from Search Console data. It was like, hey, I can look at queries, I can look at pages, but I don’t really know a lot about the people, and I also don’t know a lot about their intents.

And one of the key problems with search console data is that you can’t get outside of your own website. You don’t know about your competitors at all. Right?

Now, I didn’t have a ton of experience working with Cloudflare.

And so this project was my first build, where I tried to build Cloudflare native, really as an homage to my pal, John Murch over here, who is the biggest Cloudflare aficionado that I know.

So I built this thing, and it’s just amazing. I also wanted to build it as a way to be sticky for agencies and in house teams, because I think the biggest problem that I’m hearing about is client churn. It’s not about, do I understand vector embeddings? It’s about, will I lose my clients this month?

Will they renew their annual contract?

Will I have lost headcount? Will I have lost budgets? And I didn’t want to build something that was just an SEO tool. I wanted to build something that enabled SEO agencies and in house teams to build the proof and to build their own moat around how they communicate with clients. So I built something that allows us to have like an executive summary.

And it also, I don’t know if you can you guys even read that? Probably not. But like, the WINDS Discovery, it runs automatically and it finds when performance is going positive so that your strategist can click a button and add that to the monthly report, so that they don’t have to sit there and troll through it trying to find little wins. And if you guys could see these search terms, you’d probably get a good laugh. My favorite one is why is Noah Lerter so short?

Had to have fun. Right?

Also, I hadn’t seen a tool really that that broke down a website by topical landscape and put it into a four quarter quadrant for people to quickly be able to communicate either to the head of their team or the head, CMO at their organization. So I built that because I felt like, hey, we gotta find a way to communicate our value so that we win.

And then as content starts to decay over time, it automatically throws stuff into a content refresh loop. So this is kinda how I was thinking.

Can you see how an SEO who understands the lifecycle of content can use that domain expertise to build a whole system and a whole platform? That’s the takeaway. Not that I am awesome, but that you are capable of this. It’s going to take time and a lot of pain and a lot of scars, but you’ll get there.

Also has monthly reporting, which is pretty cool.

Anybody here a Charlie Munger fan?

Yeah, Charlie Munger is the bomb. He was one of the two founders for Berkshire Hathaway, right? And he had this thing about decision making, which was all about building what he called his lattice work.

Lattice work is when you have multiple areas of expertise.

Mike, I’ve seen him described as a multiple polymath, that is what we are talking about here. This was my old stack on the left and my new stack addition by learning everything with Cloudflare.

Basically, what I’ve been able to do is to put myself in the center. When I think about my own career, I think about developing multiple realms of expertise that allow me to step into different situations. I can speak, I can communicate, I can think critically, I can do design, I can do web dev, I can do technical SEO sometimes, content, I can manage people, I can train people.

It’s not about the code. It’s about developing all kinds of different intersections that align with who you are in order to get all kinds of leverage, which is really the biggest thing. I love this, and I keep thinking about where do I want to live in two to three years and what types of skill sets do I want to develop so that I can be uniquely valuable based on those different intersections. I don’t know if this is helpful, but I wanted to kind of take us back into the tool.

Forty six days, there’s just a lot of stats. If you build, you know that the thing that matters to a lot of these guys is the unit of work, it’s called a commit.

And usually, you want to keep that to like five hundred lines or fewer. And a thousand of those is a lot. Lots of tests.

Took this much time to get to that type of type of, build. I didn’t realize this, but apparently, if you work your ass off, you can do the work of five to twenty person teams.

That’s what what it’s called when someone becomes an operator. It’s where they develop that coding expertise on top of the domain expertise. I think that’s where people who are really walking down this path are becoming crazy, crazy valuable. When I think about my own journey, this is where I think I’m headed. It’s it’s hopefully gonna be an SEO for a long time, but I keep thinking about how I can leverage what I know in order to be able to grow my output.

This is the key thing here. Right? We don’t forget.

Okay.

I’m going share some of my scars with you because they hurt, and they were crazy impactful to how I built. This is the first one. I wrote this BigQuery query.

If you guys haven’t heard this story, it’s pretty funny.

For the SEO community, we built a patent search.

And what it enables the user to do is to look through all of Google’s patents around Google Search. And it’s free, it’s available inside our SEO community’s backdoor, which is called brain. Theseocommunity dot com. And what I was doing was going into a public dataset and pulling down all the information. The dataset was like one and a half terabytes. And I was supposed to do what’s called the batch query, where you’d say, hey, want to grab all of this and this and this and this and this, and it failed. And instead of doing a batch, it did a loop.

And in four seconds, dollars seventeen hundred query.

It hurt. It was really painful.

In sharing that story with people, I I heard a lot of great stories. I don’t know if Greg Bernhardt is here, but he told the story that he did something similar, I think, at Shopify that was about forty five times larger than mine.

When I was building this query, it was ten pm and I wasn’t paying attention, and it was a Friday night. And I did a dry run of the query, and I immediately got a notification on my phone, which I dismissed.

And then it ran.

So bugs have ghosts. I don’t know if you’ve ever heard this, but if something goes wrong once, it’s going to go wrong again. So if something like that happens, you’ve got to fix it.

I definitely paid the bill, and I built something called a hook. Do you guys know what a hook is with Claude code? Anyone use them? Okay, a couple of folks. Not a lot.

Hooks are basically shell scripts. You don’t need to know what that means so much as you telling Claude code, build me a hook that does a thing. And I built a hook, and I built also a GitHub repo that I’m going share with you guys. You can take a picture of it to grab it.

This has a whole bunch of hooks and skills and commands that I use all the time, and I’m hoping that it’s really useful for you. The first one is this database query guard. Basically what it does, it works on fifteen different platforms. And when you perform anything inside Cloud Code that’s gonna be a search, it’ll automatically pop up a warning and say, hey, that’s gonna cost you fifteen dollars Are you sure you wanna do that?

I think that’s really useful. If you’ve ever done a really bad query, you’ll know the pain that I went through. It was a super bummer. When I think about how to build on Claude and I think about being smart about it, I think the biggest thing that people probably don’t spend enough time on is this concept of context management.

This should be the biggest area of time that you spend when you’re building things, because this is how you’re going to get the smartest outputs out of the tool.

When I’m building with it, I think this is the thing that’s most closely tied to high quality output. And so I try and stay inside the first twenty percent if possible.

That sounds insane, right? Because now we have a million tokens, so wouldn’t I just wanna use a million tokens? The answer is no. You wanna always, always get out before you’re done with your first twenty percent if possible.

There’s a great command called status line inside Cloud Code that will allow you to set this up, and you’ll see this little thing like the gray picture, that CTX eighty two percent tells me that I’ve used eighteen percent. When I hit that eighty, and it’s not like, you know, at exactly twenty percent I get out, but I generally am trying to get out as fast as I can. And that ties off to a handoff skill that I built that is also in the repo. And basically, what it does is it takes the context of everything you’ve been talking about, it puts it down into sixty ish lines or so, copies it to your clipboard, and then you’ll type in clear and paste it in, and you keep going off to the races with a nice, model.

There are a lot of frameworks out there, and I’ve tried a lot of them, and I’ve had varying levels of success and joy with all of them, and I’m now almost exclusively working without them.

And so I want to walk you through how to set up a Claude file. Has anyone actually set up a Claude. Md file?

Okay.

Did you know that you have two hundred lines to say what you mean with a Claude. Md file?

I’ve put a lot of time into managing mine, and I think in the repo I shared a skill for how to structure it like this. But basically, is forty four lines long, and I at import anything that must be loaded every single session.

And then there are also reference pointers for things that don’t have to be pulled in every time, and that enables me to use a lot less tokens on the front end of every conversation.

We’ll get into memory a little bit.

One thing that I wasn’t aware of when you’re using your auto memory, there are four different subsets, user feedback, project, and reference. And when you set up your different memory files, you’re gonna find that it makes sense to structure it exactly the same way. It helps Claude really work through the context. And this is kind of like a great way to structure that file. You’ll see that at the top it has feedback, then project, then user, then reference, and that’s exactly what Andrea was talking about earlier today when he said, hey, we front load all the stuff that’s important. You put the things that are most relevant at the top and the things that are the least important at the bottom.

I have about one hundred and nineteen files, and I use that type fixing structure that I shared earlier to do it.

I also use a lot of rules, and I’m going to show you some dense slides. The dense slide isn’t super important until you get home and you can actually read it.

So this is how I like to structure it in terms of the Claude folder. It goes Claude, Claude MD, and then rules. You’ll notice inside that there’s a bunch of different rules. And then you’ll also notice that there are things called evidence files.

And they have to have the same naming convention as the rule that it’s referring to, with the exception of the evidence on the tail end. The evidence files don’t get pulled in, so you can save tokens that way until it needs to read them for actual evidence. And this is kind of like what my rules folder ends up looking like. There’s a ton of them.

Okay, couple of things.

I want to share with you some ways of thinking about this that I didn’t really know early on. I ask Claude for feedback all the time.

And I mentioned that earlier, but it’s like the key thing is, you willing to change? If you’re not using this command now, you will probably find it to be really hard to read the first time. But you will find that if you run this with a weekly cadence and you incorporate the feedback that it gives, you’re gonna find that you do much better work. It’s gonna give you sections in an HTML file. The green is like, hey, these are the things you’re doing well.

When I ran this the first time, it was like, hey, you’re great at spotting bugs. And then the red was, why don’t you plan better?

Right? So definitely read through this. You’ll get a lot better outputs. It’ll also recommend hooks for you, which is amazing. And it’ll do the same thing for skills.

And then you turn all of that feedback into new rules, new skills, new hooks, and you’ll find that your harness, the thing that you’re coding with, and also the quality of your output gets better.

Make it awesome. Okay, so I’m going to share some funny things that happened along the way. This is my favorite interaction with Opus over forty six days. I was doing a data pipeline and it kept ******** up my data pipeline, and it made it so that it wasn’t idempotent.

Idempotent means that this thing’s gonna work on Monday the same way it works on Tuesday, and you can get reliable outputs. And I kept telling it, no. No. No.

No. That’s not how to do it. And I said, you know, and it said, you just spent four hours teaching an Opus model how to build a data pipelining, correcting it each time. And and then it was like, yeah, it was I know you just made me mass delete my own code three times in one session, which I thought was super funny.

Clearly, I’m a dork. But, okay.

So this conversation on the left is the one that started me learning how to work better. I basically was on vacation, driving in the back seat of our car, and I was able to code for an entire week of vacation, which is amazing. Don’t tell my wife. We all had a lot of fun.

But this conversation was the one where I was like, hey, what the ****? Every time you deliver code, it’s mostly broken. And I go through these crazy debugging sessions. And we had a heart to heart.

It was great. Claude really had my back. And then we came up with a new way that we could collaborate. We created all these hooks.

It was like, if this is its feedback to me, it goes, hey, you are not allowed to deploy on weekends. You are not allowed to deploy after six o’clock. You can only deploy things that are five hundred lines long or fewer.

You have to do this, you have to do testing. Before that, my tests were not all that expansive, but now I do tests for every single function that I build. And I’m not doing crazy integration tests, I’m doing shape tests, which just say like, hey, when you run this function, do you get anything back? Which is really like, is it totally busted?

Okay, so this what happened.

We found that with all of these new rules, this was the before and after.

I went from eighteen hundred lines down to five twenty one, which was amazing. And then my the percentage of code that I shipped, and this is me being vulnerable, not that most people get vulnerable about their code, but something like eighty plus percent of the code that I was producing before the rules, I looped back through and had to fix something. Right? And that number dropped to fifteen percent after.

So this is why this stuff matters, because your time is valuable and all those tokens that you’re burning, debugging, like, that’s money. Right? So, like, you wanna incorporate these these rules. Another couple things that I do, I use verbs.

I hope I’m not too much of a narcissist. I hate the fact that my name is in these, but I made one rule and I put my name in it just because I figured it would be a safe namespace, right, like with my code base. And then it couldn’t find better names and I’m super bummed. So when you go on the repo, you’re gonna see these.

They all do different things And I basically can use them in sentences like this, which is really rad. I don’t even have to think about the order of them. Often it will put them in the right order for me. And so I’ll say like, Noah fixed the dashboard, is showing empty scorecards, then Noah planned this other thing, and then Noah shipped.

And it makes it so that I can speak in shorthand and the skill that I spend a lot of time crafting is gonna have a nice big impact downstream.

This one I love, which is in the repo, it’s called QA Explorer, it uses Playwright to go look at a UI for you, and it’ll find the errors and then it’ll debug them. I also have a variant of it that I can use. This is what it looks like when it’s actually doing the thing. It’ll go look at a page and crawl it and find stuff. I also have a variant of this that you can use. How many of you guys use this kind of QA Explorer with Playwright to improve your UX?

You do? Nice. So this will do eight passes and fix it eight different times in a row, which is super rad.

Docs update, when I built this application, I built it in a way where I can run a skill and it’ll update the docs for the entire application, including screenshots, which is pretty rad. This is kind of what they look like.

And that’s in the repo. I think monitors in the repo also, this is great for debugging. It’ll open up another session that’s tailing the live, all the live stuff, and you can watch all of the responses coming back, and you can feed that back up to Claude so it can use it for debugging, which is great.

I’m going to share a couple of different things really quickly.

My favorite prompt. The structure of it is really simple. Year out, twenty twenty hindsight, tap into this concept of regrets, demand elegance. This is what it looks like in practice.

Pretend it’s a year out, and we’re looking back with twenty twenty hindsight with a full year of complaints from customers under our belts. What would we regret not building? What would we regret building?

Take that knowledge to create an understanding of what an elegant solution would have looked like, and go into planning mode in order to build that elegant solution now. Hey, let’s shortcut a whole year of complaints. Right? If you’re not doing this, it’s really great.

If you have a better version of it, I’m all ears. This is just me running the mouth at Claude, but I found this. If you feed this all in, in a recursive three to five iteration pattern, you get to a place where after four to six cycles of this, you keep asking it, do you have any regrets? Do you have any concerns?

And it will say, yeah, this is crap because and it will list them out and you incorporate those in. After about five cycles, you get to a place where it’s like, Nope, ship it. Which is a lot of people don’t go to that level. I always try and focus on the simplest, the fastest and the cheapest to own that I won’t regret.

So if you have question you want to ask, I think that’s a fantastic structure.

Friction, I think that’s the core when we think about good UX as an SEO, we always think about that. And when I’m building things, I’m always asking it. Every iteration, it’s like, how can I have less friction for my users and less friction for our support team if this thing ever gets off the ground? And I ask them over and over and over and over.

A couple of quick wins.

Ask Claude what you’re doing wrong. Screenshot the answer. Try and fix it this week.

Audit your Claude. Md file. Count the lines. Try and cut it in half if you can.

Name one of these out loud and write about it.

Be vocal, be vulnerable. You’ll be shocked at what happens.

And then try and answer this question, if I could leave you with something. None of us know what the future is going to bring. Find your intersections.

Find the places that you uniquely have it.

We all have overlapping skill sets that are just a little bit different. Think about yours. Think about where you are, where you want to be, what that next one looks like, and work towards developing the skills to get there. You’ll be shocked at how amazing it is. A couple of quick things, seoloop. Io, if you want to check it out. Got a fun little landing page.

Sterling Sky, where I’m lucky enough to be the director of innovation, is hiring. We do amazing work in local.

I would love to have you join the team.

And here’s my oh, that blue is tough. Here’s my stuff.

Thanks, guys. I had a lot of fun. It was really great. Thanks.

Everybody give it up for Noah Lerner, y’all.