What Being a CTO in Publishing Taught Me About SEO, and Why AEO and GEO Matter Now

I used to judge a website by how well it was built

For most of my career, I looked at a website the way an engineer does. Is the architecture sound? Is it fast? Does it stay up? Can we ship changes safely? Will the infrastructure hold when traffic spikes?

Those are good questions. I still ask all of them. But when I became CTO of a media publishing platform, I found out they weren’t enough.

We ran a portfolio of media titles on a shared platform, competing for readers with media companies far larger than us. Our editors produced good content. A lot of it still lost on search rankings and social feeds to publishers with more money and more people.

That was hard for an engineer to accept at first. The site worked. It was reliable. And it didn’t matter very much, because the readers we wanted weren’t finding it.

If nobody discovers the content, the technology behind it doesn’t matter very much.

In publishing, content is the product and the distribution channel

At a software company, marketing exists to bring people to the product. In publishing, the content is the product, and it’s also how people find you. Each article is something a reader came for and, at the same time, the reason they found the site in the first place.

That changed how I thought about the platform. An article wasn’t finished when an editor pressed publish. It was finished when it could be found, understood, shared and read on whatever device someone happened to be holding. A lot of that depended on engineering.

It also explained why content marketing works for companies outside publishing. A useful article that answers a real question keeps bringing people in long after it’s written. Content doesn’t replace a product, but for a lot of companies it’s the first part of the product anyone sees.

Search intent changes what you should build and write

Before publishing, I thought of search as a ranking problem. Get the keywords right, get the page indexed, move up the list.

Working alongside editors taught me to start somewhere else: what was the person trying to do when they typed that search? Someone looking for a quick fact, someone comparing options and someone trying to follow steps are three different readers, even when their searches share most of their words. The page that serves one of them well usually serves the others badly.

Search intent is the goal behind a search: to learn something, find a specific site, compare options or get something done. It decides what kind of page should exist, how it should be structured and what a reader should be able to do next.

For engineering, intent turned into concrete requirements. It affected page templates, how much content loaded before the first scroll, how we structured content in the CMS, and which pages linked to which. It’s the same habit I describe in the most expensive engineering work is work nobody needed: start from the need, then decide what to build.

Technical SEO turned out to be engineering work

I had assumed SEO belonged to marketing. Much of it does. But a large part of what decides whether a page can be found is decided in the codebase, long before anyone in marketing sees it.

Technical SEO is the engineering side of search: making sure search engines can crawl, render, understand and index a site’s pages, and that those pages load quickly and work well on every device. Most of it lives in architecture, templates, routing and infrastructure.

This is the part I had to learn properly, because my team owned it:

Site architecture

How sections and titles relate to each other, and whether a reader or a crawler can tell what the site is about from its structure.

URL structure

Readable, stable URLs that describe the page and don’t change when a framework or CMS does.

Redirects

Permanent redirects from every old URL to its closest new equivalent whenever something moves.

Canonical URLs

One preferred URL for each piece of content, so syndicated copies, tracking parameters and duplicate paths don’t compete with the original.

Structured data and metadata

Titles, descriptions and machine-readable markup that tell search engines what a page is, who wrote it and when.

Sitemaps

A current list of the pages that matter, so new content gets discovered quickly.

Internal linking

Links between related pages, which help readers keep going and show search engines how topics connect.

Crawlability

Making sure important content is reachable through links and included in the HTML a crawler actually receives.

Performance and mobile

Fast pages that hold steady while loading and work properly on a phone, measured with Core Web Vitals.

Migrations

Redesigns and platform moves that don’t leave a trail of broken links behind them.

None of this was new technology. Most of it was ordinary engineering discipline, applied with an extra question in mind: what does this change do to how people and search engines find the content?

Why should a CTO care about SEO?

Because engineering decisions change how a company gets discovered. A routine change to URLs, rendering, templates or page speed can undo years of accumulated search value, and the people who would notice first often aren’t in engineering.

That was the lesson that stuck with me most. Search value builds up slowly: pages earn links, rankings and reader trust over years. It can be lost in a single release by a team that had no idea it was there.

These are the kinds of decisions I learned to look at twice:

Changing URL structures

A cleaner URL scheme looks like a harmless improvement. Without a careful redirect map, every link and ranking the old URLs earned is thrown away.

Heavy client-side JavaScript

If content only appears after scripts run, crawlers may see an empty page or index it late. Google can render JavaScript, but its own guidance explains why server-rendered or prerendered HTML is the safer default.

A beautiful redesign

A redesign can look better and still remove headings, collapse text into images, drop internal links or bury articles three clicks deeper.

Poor information architecture

Excellent content that no hub, category or related link points to is close to invisible, to readers and crawlers alike.

Slow pages

Slow pages lose readers before the first paragraph appears, and page experience is part of how search engines evaluate a site.

Deleting “old” pages

A page can look obsolete and still be earning backlinks and steady traffic. Removing it without a redirect removes all of that too.

None of these come from careless engineers. They come from teams that measure a release by whether it works, without anyone asking what it does to discovery. That’s a leadership gap, not a skills gap.

Content has to work beyond Google

Search was only one channel. A lot of our readers found articles because someone shared them, and that taught me social media optimization as a separate discipline from SEO.

A link shared in a feed is judged in a second or two, on a title, a short description and an image. If the Open Graph data was missing or wrong, the card showed the wrong image, a cropped headline or a description pulled from the site navigation. The article underneath could be excellent and nobody would click.

So social cards became part of the platform too: a headline written for a feed, which isn’t always the same as one written for search; a description that gives a reason to click; an image sized for each platform; and pages that load quickly when someone arrives from a phone. It also meant paying attention to how people actually discovered content on each platform, rather than assuming everyone arrived from a search box.

Traffic was never the real goal

Once you can measure traffic, it’s tempting to treat it as the scoreboard. Publishing taught me that traffic tells you very little on its own.

The more useful questions were about the reader:

• What did people search for before they arrived?
• Which channel brought them: search, social, a newsletter, another site?
• What did they do once they got here? Did they read, scroll, click through to something related, come back later?
• Did the page actually answer what they came for?

A page that ranks for a search it doesn’t answer brings in visitors who leave immediately. That isn’t success, even when the traffic chart says it is. Because so much of our audience depended on algorithms we didn’t control, we measured every release against traffic and engagement. Measurement ended up shaping much of the roadmap.

What it changed about how I see the CTO role

The biggest shift wasn’t technical. It was realizing that engineering couldn’t work as a separate function in that business.

Editorial knew what readers wanted. Marketing knew where they came from. The business side knew which audiences and titles mattered most. Engineering controlled whether the platform made any of that easy or hard. Every one of those groups was affected by decisions the others made, often without knowing it.

The decision that came out of that was to treat distribution as something the platform did, rather than something editors did after publishing. We put structure into the CMS, made rendering fast and cached, and generated metadata for search engines and social cards automatically, so every title got it by default and improvements carried across the portfolio. Over that period, organic traffic, social traffic and social engagement each grew 50%. I’ve written up the decisions behind that in the publishing platform case study.

A platform capability beats a process. It still works on the busiest day.

A CTO doesn’t need to become the company’s SEO specialist or content marketer. There are people who do that work far better. But a technology leader should understand these systems well enough to recognize when an engineering decision helps or hurts the company’s ability to be found, and to bring the right people in before the release, not after the traffic drops. That’s a large part of how I think about working across product, marketing and leadership.

Discovery is changing again

For years, the model we optimized for was simple:

Search

Search → results page → click → website.

AI answers

Question → answer, sometimes with a source attached.

More and more, people ask ChatGPT, Google’s AI features, Perplexity, Claude or another AI system a question and expect the answer right away. Some of them never visit a website at all. Others click a cited source to check the answer or go deeper.

That raises a question that is part engineering and part content:

How do we create information that people can understand, search engines can index, and AI systems can reliably interpret, retrieve, cite and use?

Answer Engine Optimization (AEO) is the practice of structuring content so search features and AI assistants can pull a clear, direct answer from it. Generative Engine Optimization (GEO) is the practice of making content and the entities behind it easy for generative AI systems to understand, trust and cite when they write an answer.

The term GEO comes in part from a research paper, GEO: Generative Engine Optimization, that tested how changes such as adding citations, quotations and statistics affected how visible a source was in AI-generated answers. The field is young, and I’m treating most of what I read about it as hypotheses rather than settled practice.

What I’m learning about AEO and GEO

I’m still learning this. Some of it is familiar from publishing, some of it is new, and I’m testing it on my own sites, including this one. Each post here ends with short answers to the questions it covers, the pages carry structured data that describes who wrote them and what they’re about, and I try to keep the people, organizations and projects I mention consistent from page to page.

This is what I’m paying attention to:

• Be direct. Answer the question near the top, in plain language, without a long warm-up written for keyword density.
• Structure around real questions. Headings that match what people actually ask, not every variation of a keyword.
• Write passages that stand alone. An AI system may quote one paragraph with nothing around it. That paragraph should still name what it’s about and make sense.
• Show first-hand experience. Evidence, data, examples and original observations are the parts nobody else can write, and they’re what make content worth citing.
• Use semantic structure. Clear headings, lists and tables, and an information architecture that shows how pages relate.
• Keep content readable by machines without hurting people. Server-rendered HTML, accurate structured data and fast pages help both.
• Link with meaning. Internal links that connect related topics show what a site actually knows about.
• Aim to be cited, not just ranked. A page that’s accurate, specific and clearly sourced is more likely to be used in an answer than one written only to rank.

Most of that list is just good writing and good engineering. That’s partly the point.

Is SEO dead because of AI search?

No. AEO and GEO don’t replace SEO; they expand the problem. A technically healthy, authoritative and useful website is still the foundation that search engines and AI systems both depend on.

Google’s own guidance on AI features says the same SEO best practices still apply, and its advice on helpful, reliable, people-first content reads a lot like what makes a page worth citing. AI systems still need to crawl pages, still prefer sources that look trustworthy, and often still send readers to a website to check or go deeper.

What changes is the goal. Discovery is no longer only about earning a blue link. It’s about being the source an answer is built on, which raises the bar on clarity, accuracy and evidence.

The questions I ask when I build something now

Publishing changed the questions I ask about software. “Does it work?” is still first. It just isn’t the last one anymore:

1. Can people find it? Through search, social, links from other sites, or wherever they already are.
2. Can search engines understand it? Crawlable HTML, stable URLs, accurate metadata, a clear structure.
3. Can AI systems understand it? Clear entities, standalone answers, structured data that matches what’s on the page.
4. Does it answer a real question? One that someone is actually asking, not one we invented to fill a keyword.
5. Does it create value after we ship it? Measured by what readers did, not just by the release going out.

I asked versions of these on the Berkeley Omnium website and the Union City Smog Check redesign, where answer-first pages and structured data were part of the build from the start rather than a cleanup task afterward.

Sources

The technical points above follow Google Search Central’s documentation and the research paper that introduced the term GEO. Everything else is my own experience.

• Google Search Central: Creating helpful, reliable, people-first content
• Google Search Central: Site moves with URL changes
• Google Search Central: Consolidate duplicate URLs (canonicalization)
• Google Search Central: JavaScript SEO basics
• Google Search Central: Core Web Vitals
• Google Search Central: AI features and your website
• The Open Graph protocol
• Aggarwal et al., GEO: Generative Engine Optimization (arXiv)

Short answers