The part of SEO nobody warns you about

I remember the audit. Fifty-some pages, four people on it for three weeks. Every crawl issue, every thin content cluster, every missing hreflang tag, every internal linking problem mapped to estimated impact. Color-coded by priority. The kind of document you're proud to send.

The client was a Fortune 500 hardware brand. Global footprint, a name everyone recognizes. We presented the audit in a 90-minute meeting with their main point of contact, the person who had hired us. He sat there, taking notes, asking sharp questions, thanking us at the end. We walked out thinking we had nailed it.

Shortly after, the relationship started cooling. Emails got shorter. The follow-up call got rescheduled twice, then quietly dropped. We never landed the implementation phase that was supposed to follow the audit.

It took me embarrassingly long to figure out what had happened. Our contact at the client was the person responsible for SEO inside that company. He had hired us, on paper, to do an audit. But what he had actually hired us to do, what he needed to do his own job, was deliver a document he could share upward to validate the work his team was already doing. Our audit, doing exactly what audits are supposed to do, instead documented every place his team had fallen short. We hadn't written a validation. We had written a layoff memo, addressed to the person who signed our contract.

The strategy was right. The strategic context was wrong. And nobody had told us about the context, because we never asked.

The job you think you're walking into

That was an agency engagement, so the easy lesson would be that consultants are outsiders who miss the office politics. But I've spent years since leading SEO from inside large companies, and the inside is where the lesson actually sharpened: the pattern is universal, and being on the payroll doesn't exempt you from it. If anything it raises the stakes, because you can't hand over a deck and walk away when the quarter ends.

Here's the thing about joining a large company to lead SEO. You think the job is SEO. Audits, keyword research, content optimization, technical fixes, link building strategy. The stuff you trained for. The stuff you're good at.

And you are good at it. That's why they hired you. But the job they hired you for and the job you'll actually do are two different things, and nobody tells you this during the interview.

The actual job is diplomacy.

Longstanding organizations have teams that run like well-oiled machines. Each team has its rhythm, its tools, its internal language, its own set of KPIs that have nothing to do with yours. The content team measures engagement and brand sentiment. The dev team measures sprint velocity and uptime. Product marketing measures pipeline influence. None of them woke up this morning thinking about organic traffic.

And then you show up. The SEO person. With your audit. With your "opportunities." With your implicit request that every team in the building change something about how they work so that your numbers go up.

You're not a colleague yet. You're a disruption.

I wish someone had told me this before I made every mistake in the book.

The audit, revisited

Let me back up to that hardware client, because the failure was more specific than "we missed the political context."

The failure was that we had led with our expertise instead of our curiosity.

We had come in with a mindset trained by years of agency work: diagnose the problem, prescribe the solution, deliver the document. That works when the client genuinely wants a diagnosis. They've already bought into the premise that something needs to change.

The hardware client hadn't bought into that premise. Or rather, the person who hired us hadn't. From his angle, the company's SEO was fine. The point of the audit was to confirm that, in a credible third-party voice, so he could keep doing the work he was already doing. He wasn't shopping for a diagnosis. He was shopping for validation.

We were solving a problem he didn't have, using language he didn't want spoken out loud, and surfacing risks he had worked hard not to surface.

The polite cooling of the relationship wasn't resistance. It was self-preservation. He was protecting his job. We had not bothered to learn that his job was the thing standing in front of our recommendations.

That was the first lesson, and it came from the outside. The next one came from the inside.

The coffee that changed everything

A few months into my role at Quadient, I had a growing backlog of technical SEO requests for the web engineering team. Site speed work, structured data, canonical cleanups, the usual list that comes out of any enterprise audit. I knew the team had limited bandwidth. Every quarter I would hand over my prioritized list. Every quarter most of it would slip.

I could have escalated. Built a case for leadership, made noise about technical debt, fought for sprint capacity. The agency-trained reflex was strong. Instead, I tried something different.

I scheduled a coffee with the Head of Web Engineering. Not a meeting in a conference room with a ticket open and an agenda. A real coffee. And I asked him one question: "What are the things you're trying to get approved that are stuck because of leadership resistance?"

He paused. Then he talked for forty minutes.

His team had been pushing for a full move to a headless CMS architecture. They had a clean technical case for it: better separation of concerns, faster page loads, easier internationalization, much improved mobile performance. They had been blocked for months. Leadership saw it as a big-budget engineering project with no clear business case beyond "the engineers want it."

Here is what I noticed while he talked. Almost every benefit he was describing had a direct SEO impact. Faster load times. Better mobile performance. Cleaner URL structures across country sites. Easier hreflang implementation. The headless migration was, from my angle, essentially a complete technical SEO overhaul packaged as an infrastructure project.

So I made it my talking point. Over the next three months, in every meeting where I had a seat (marketing leadership reviews, quarterly business reviews, strategy sessions with the CMO), I worked the headless migration into the conversation. Not as his project. As a strategic SEO infrastructure investment with significant organic traffic upside. I built the business case from the demand side. He had the technical case from the supply side. Together it worked.

The project got approved. Budget allocated. Roadmap locked in.

From that day on, his team treated my requests differently. Not because they suddenly cared about SEO for its own sake, but because I had become someone who fought for them when it mattered. When I needed a small technical fix, it stopped sitting in the backlog for six sprints. When I needed a quick implementation review, I got it within days. We had built actual reciprocity, the kind that doesn't show up on any org chart and quietly determines what actually ships.

The lesson I took from this is the inverse of how SEO advice usually gets framed. Most articles tell you how to get the dev team to do what you want. The better question is: what do they need that I can help them get? Once you can answer that, the directional flow of the relationship changes. You stop asking for favors. You start trading them.

Learning to listen before you prescribe

The instinct of every SEO professional I know (including me, especially early in my career) is to diagnose and prescribe. You see the problem. You know the fix. You want to implement it. The gap between "I know what to do" and "it's actually done" feels like organizational dysfunction. It feels like bureaucracy. It feels like people who don't get it.

But most of the time, the gap isn't dysfunction. It's the normal texture of a large organization where dozens of smart people are all trying to do their jobs well, with finite time and resources, and your priority is not their priority.

The first step, genuinely, is to shut up and listen.

When I started working with a new team (whether at a new company or inside the same organization), I learned to spend the first two weeks doing almost nothing visible. I'd schedule introductory meetings, but I'd structure them differently than I had with that hardware client. Instead of showing what I could do for them, I'd ask what they were working on. What tools they used. What their biggest headaches were. Who influenced their priorities. What had been tried before and hadn't worked.

The ratio of them talking to me talking should be at least three to one. Ideally four to one.

This isn't just politeness (though it is polite). It's intelligence gathering. You're learning the map of the organization: who has influence, who has capacity, who is already sympathetic to what you're trying to do, and who has been burned by a previous SEO person who came in with a stack of recommendations and disrupted their quarter.

Wait, let me be honest about something. There's a selfish reason too. When you let people talk about their work, they feel respected. And people who feel respected are dramatically more likely to help you later. This isn't manipulation. It's the basic social contract of collaborative work. But it's worth naming because a lot of technical people (and I include myself here) underestimate how much the interpersonal groundwork matters.

You can also learn a lot by seeing people both in a group setting and individually. In a meeting of eight people, the loudest voice isn't always the most influential one. The person who says little in the group but sends you a thoughtful follow-up email? That's often the one who'll become your champion inside their team. Pay attention to the quiet ones.

Speaking each team's language

Here's a mistake I see over and over, and I made it myself at Quadient before I learned better.

SEO professionals sit at the crossroads of multiple specialties. You talk to developers, content writers, product managers, executives, designers, data analysts. Each of these groups has its own vocabulary, its own frameworks, its own way of thinking about problems.

The dev team talks about tickets, sprints, specs, and technical debt. The content team talks about editorial calendars, brand voice, engagement metrics, and publishing workflows. The product team talks about roadmaps, user stories, and feature prioritization.

If you walk into the dev team's standup and start talking about "content optimization" and "keyword cannibalization," you've already lost them. Not because they're not smart enough to understand. Because you're asking them to translate your world into theirs, and they don't have time for that.

The fix is simple in theory, hard in practice: you learn their language and present your work in their terms.

When I talk to developers, an SEO recommendation becomes a ticket with clear acceptance criteria, estimated scope, and a note on which existing epic it relates to. When I talk to the content team, it becomes a brief that fits into their existing workflow, with specific guidance on what to include (not a fifty-point optimization checklist, but two or three things that matter most for this piece). When I talk to executives, it becomes a slide with a number, a trend line, and a business outcome.

Same underlying work. Different packaging. And the packaging is not superficial. It's the difference between getting something done and having it sit in someone else's backlog for six months.

The Microsoft Word lesson

This is maybe the most concrete example I can give, and it's one I keep coming back to because it captures the whole pattern in miniature.

At one company I worked with, the content team used Microsoft Word for everything. Their entire workflow (drafting, editing, reviewing, approving) lived in Word documents passed back and forth via email and SharePoint. It worked for them. They were comfortable with it. They'd been doing it this way for years.

The SEO-optimal thing would have been to move them to SurferSEO or Clearscope. These tools give real-time feedback on keyword usage, content structure, readability, and competitive analysis. They're genuinely better for producing SEO-friendly content. That's not even debatable.

But asking a content team to abandon their entire workflow and learn a new platform because the SEO person says so? That's a non-starter. You will be met with resistance, and the resistance is rational. You're asking them to absorb risk and friction so that your metrics improve. Why would they do that?

So instead, I suggested integrating SEMRush Writing Assistant. Is it a subpar tool for content optimization? Yes, honestly. The recommendations are surface-level at best. But it integrates as a plugin directly into Microsoft Word. The content team didn't have to change anything about their workflow. They just had an extra panel on the right side of their screen with some suggestions they could look at or ignore.

Nobody's life got harder. Nobody had to learn a new platform. Nobody had to change their process.

And here's what happened over the next few months. The team got used to having optimization feedback in their workflow. They started asking questions: "Why does this tool say my readability score is low? What does that mean? Is there something better for this?" They started caring about the thing I cared about, not because I told them to, but because the tool created a natural on-ramp to curiosity.

Six months later, the two most engaged writers on the team were willing to try Clearscope. A year after that, the whole team had migrated. And by then it was their idea, not mine.

The lesson: driving change in a large organization is incremental. You don't get to skip to the end state. You find the smallest possible intervention that doesn't disrupt anyone's day, and you let it do the work of creating curiosity and buy-in over time.

Depending on the organization, this process takes months to years. There is no shortcut. Anyone who tells you there is has never actually done it inside a company with more than 200 people.

Building your own SEO territory

There's one more move that I've seen work consistently, and I used it myself.

In large organizations, updating existing content is a negotiation. A product page might need sign-off from product marketing, legal, brand, and the web team before you can change a title tag. A blog post might be owned by a content lead who has her own editorial vision that has nothing to do with organic traffic (which is fine, not everything has to bring traffic, there are other goals). You can spend months trying to optimize pages you don't control, and every optimization requires a meeting, a review, an approval cycle, and a compromise.

The alternative: advocate for the creation of a new section on the website. A resource hub, a glossary, an educational content library. Something that sits outside the existing turf.

This is not about empire building, though I understand if it sounds like it. It's about creating a space where you can move fast, test hypotheses, and build credibility through results. When you own the structure and you define the content plan, you don't need five approvals to add internal links or adjust heading hierarchy. You can publish in days instead of months.

And as this section grows (and it will grow, because you're building it with organic visibility as the primary design constraint), something interesting happens. People start coming to you. "Hey, our product page isn't performing as well as your resource articles. Can you do for us what you did with that section?" Suddenly you're not pushing anymore. You're being pulled.

That shift, from pushing your expertise onto reluctant teams to being invited in because they've seen what you can do, is the most important transition in organizational SEO. Everything before it is hard. Everything after it is still hard, but a different kind of hard. The kind where people want to work with you instead of around you.

What I'd call it, looking back

I've been thinking about this pattern for a while now, across Quadient, across the 60-some companies I consulted for over the years, and now watching similar dynamics play out at Adobe from the engineering side (where I'm building tools, not doing SEO, but the organizational physics are eerily similar).

The pattern is this: the SEO professionals who succeed in large organizations aren't the ones with the best audits. They're the ones who understand that their job is to build an embassy inside a foreign country.

You're a guest. You don't get to rewrite the laws. You don't get to impose your culture. You learn the local customs, you make yourself useful, you build trust one relationship at a time, and slowly, over months and years, you earn enough goodwill that people come to your embassy voluntarily. Because they've figured out that what you're offering is genuinely useful to them.

The audit is the easy part. The diplomacy is the actual job.

And nobody trains you for this. Not a single SEO course, certification, or conference talk I've ever attended spent meaningful time on organizational dynamics, stakeholder management, or the art of the incremental intervention. We train people to diagnose and prescribe, and then we're surprised when they can't get anything implemented inside a company that has its own immune system against unsolicited prescriptions.

I don't think this changes anytime soon. The skill gap between knowing SEO and practicing SEO inside a large organization will remain, because it's a fundamentally different kind of skill. One is technical knowledge. The other is political awareness, patience, empathy, and the willingness to let your fifty-page audit sit in a drawer while you drink coffee with the Head of Web Engineering and learn what his team is actually trying to get approved.

The coffee matters more than the audit. I wish I'd learned that sooner.