Baby Got Back

If you're responsible for a website but have no desire to become a web developer, this article is for you. You may be a CEO, CMO, founder, communications leader, or the person ultimately responsible for making sure a new website does what the organization needs it to do. You understand the business, the audience, and what success should look like. Then, somewhere in the project, someone starts talking about metadata, indexing, canonical URLs, alt text, Open Graph, schema, and crawlability.

It can be tempting to think: That's the technical stuff. The development team has it. They may. But here's what I learned while rebuilding our own website: you don't need to know how to implement the back end. You do need to understand what it's supposed to accomplish, what should be included in your scope, and what questions to ask before someone tells you the website is finished.

Because some of the smallest fields on your website are helping determine how much bigger the story of your organization gets introduced to the world.

I thought I understood SEO

Going into our website redesign, I had a pretty good working knowledge of SEO: creating useful content, understanding what people are searching for, using those terms naturally, building clear navigation, and publishing thoughtful case studies and articles that demonstrate genuine expertise. All of that still matters.

Then I started working through the back end of our own site: page titles, meta descriptions, alt text, Open Graph, canonical URLs, structured data, accessibility, and indexing. No single field was particularly complicated. What surprised me was how much they worked together.

Great content creates value. The invisible architecture around it helps that value become discoverable, understandable, and usable. That distinction changed the way I thought about the website.

The website you see isn't the whole website

Most of us naturally evaluate a website by what we can see. Does it look good? Is the message clear? Can I find what I need? Does it work on my phone? Does it feel like us? Those are essential questions.

But behind that visible experience is another layer communicating information to search engines, social platforms, assistive technologies, browsers, and, increasingly, AI-powered systems. Consider what happens to a single article after you publish it.

Google needs to discover and process the page. LinkedIn needs to know which image, title, and description to show when someone shares it. A screen reader needs meaningful alternatives for important visual information. Search and other systems need enough context to understand what they're encountering. Your customer may never see most of that infrastructure, but they experience its consequences.

This became much more important once we stopped thinking only about Google

The old mental model of SEO was remarkably simple: Blogs + Keywords = Visibility. That was never really the whole story, and it is even less useful now.

People still search Google, of course. But discovery happens across a much larger ecosystem. Someone might encounter your organization through a search result, LinkedIn post, AI-generated answer, image, recommendation, article, social preview or content someone else has shared. And people aren't always searching with two or three keywords anymore.

They may ask:

Which branding firms understand both healthcare and accessibility?

What should our company consider before a rebrand?

Who has experience translating complex technology for investors?

So the question becomes bigger than: Do we rank for this keyword? Have we created enough clear, useful, and well-structured information for people and systems to understand what we actually know?

No, this doesn't mean writing for robots

In fact, nearly the opposite. Google continues to emphasize helpful, reliable, people-first content and explicitly identifies keyword stuffing as a spam practice. Its guidance for AI experiences in Search makes a similar point: there is no secret new AI optimization trick. The fundamentals still matter—valuable content, technical accessibility, clear page elements, and information search systems that can access and understand.

There is no metadata field where your developer can type: Please recommend us to CMOs. There is no schema markup that guarantees an AI citation.

The goal is still to create something genuinely worth finding. The back end helps create the conditions for it to be found and interpreted.

Accessibility was one of our most important discoveries

This was where several pieces suddenly connected for me. Accessibility and discoverability are not the same discipline, but they frequently reward the same good decisions: clear structure, meaningful descriptions, logical relationships and fewer assumptions about how someone will experience information.

Alt text is a perfect example. Its primary job is accessibility—to give someone who cannot see an image the essential information it conveys. It should not become a convenient box for SEO keywords.

An image description can provide richer context. The filename can provide another signal. The page itself establishes the larger subject. Once we stopped trying to make every field accomplish everything, the system became much clearer. Good discoverability isn't about making every field say more. It's about making every field do its job.

What does good look like?

Success isn't a perfectly populated spreadsheet of metadata. It's when the visible and invisible parts of the website reinforce one another. Search results introduce your pages clearly. Shared links use the right image and description. Important visual information is accessible. Search systems can reach your content. Related ideas connect logically. AI systems have clearer evidence about what your organization actually does.

Most people will never notice any of it. They'll simply encounter an organization that is easier to find, easier to understand, and easier to trust.

What should you ask before your website launches?

This is the part I wish I'd understood earlier. You don't need to know how to write JSON-LD or configure a canonical tag. You need to be able to ask intelligent questions about the outcome. Before launch, I would want answers to these:

• How are SEO titles and meta descriptions being handled across our important pages?

• Are accessibility and meaningful alt text included in the process?

• How are social-sharing previews and Open Graph information being controlled?

• Have we confirmed that the pages we want discovered can be crawled and indexed?

• Are canonical URLs and appropriate structured data being handled?

• Do our internal links help people and search systems discover related content?

• Have we reviewed performance, mobile experience, and accessibility before launch?

• Who owns these fields after launch?

Your agency or developer may divide these responsibilities differently. That's fine. What matters is knowing that somebody owns them.

The back end is part of the architecture

This was the shift for me. I stopped thinking of visibility as something added after the website was built and started seeing it as part of the system: content, structure, context, accessibility, and technical health working together.

It's also where our thinking about Intelligent Discoverability™ began to sharpen. Search is part of the picture. The larger opportunity is helping an organization become easier to discover, understand, and represent accurately wherever people encounter it.

You don't need to master every technology behind that. Know what good looks like—and know enough to ask whether it's part of the build.

A plain-English guide to the back end

Think of this as a translation guide for the next time one appears in a proposal, CMS, or conversation with your development team.

SEO title / title tag
The title that helps search engines understand the page and may appear as its headline in search results. Why it matters: Without an intentional title, the way an important page appears in search results may be unclear, generic, or poorly matched to its content.

Meta description
A short description of the page that search engines may use beneath the title in search results. Why it matters: It gives you an opportunity to explain why the page is relevant before someone clicks. Search engines may still choose different text when they believe it better matches the search.

SEO / AI description
A richer internal or CMS description that explains what a page, article, image or resource is about when your website provides a field for it. Why it matters: Clear, descriptive context helps create a more consistent understanding of your content across the website and the systems that interpret it. Unlike the SEO title or meta description, this isn't one universal standardized field—what it does depends on how your CMS and site are configured.

Open Graph (OG)
Information that helps control how a page looks when its link is shared on platforms such as LinkedIn. It can specify the title, description and preview image associated with the page. Why it matters: Without intentional Open Graph information, a shared link may pull an unexpected image, generic title, incomplete description—or whatever information the platform can find on its own. You created the page; ideally, its introduction should look intentional too.

H1, H2, H3 headings
The hierarchy used to organize information on a page. Why it matters: Good headings make content easier to scan and help communicate which ideas are primary and which belong underneath them.

Alt text
A text alternative communicating the essential information or function of an informative image. Why it matters: Someone who cannot see the image should still be able to access the information that matters. Alt text is primarily an accessibility field, not a place to stuff SEO keywords.

Image description
Additional context explaining what an image represents and why it matters within the larger story. Why it matters: When your CMS supports a separate description field, it gives you room for richer context without forcing alt text to do two different jobs.

Internal link
A link connecting one page of your website to another. Why it matters: Without thoughtful internal links, valuable pages can become little islands—harder for visitors and crawlers to discover naturally.

Canonical URL
A signal identifying the preferred URL when multiple or similar URLs could represent the same content. Why it matters: It helps search engines understand which version you consider authoritative rather than leaving them to sort it out themselves.

Structured data / schema
Machine-readable information that can provide additional context about things such as your organization, articles, people and page relationships. Why it matters: It can help systems interpret what they're encountering more accurately. It does not guarantee rankings, special search treatment or AI citations.

Crawlability
Whether search engines can access and follow the pages and links on your website. Why it matters: If an important page can't be reached by a crawler, all the careful optimization on that page has limited value.

Indexing
The process through which a search engine analyzes and may add a page to its searchable index. Why it matters: A page being live on your website doesn't automatically mean it has been indexed or will appear in search results.

XML sitemap
A file that tells search engines about URLs on your website that you want them to know about. Why it matters: It provides another way for search engines to discover important content, particularly as a site grows.

Page performance / Core Web Vitals
Measures related to aspects of the user's page experience, including loading, responsiveness and visual stability. Why it matters: A beautiful website that loads slowly, jumps around or responds poorly can undermine the experience before someone ever reaches the content.