A content map for AWS serverless search intent

A serverless content strategy should begin with workflows, not an isolated list of keywords.

Developers search for the thing they are trying to ship or fix: an API backed by Lambda, an EventBridge integration, a queue worker, a DynamoDB access pattern, or a safer deployment path.

The site should mirror that intent.

Map content to the reader's stage

The same technical topic can represent several different questions:

• Learn: What is an event-driven architecture?
• Decide: Should this workflow use EventBridge or SQS?
• Build: How do I define the pattern in AWS CDK?
• Operate: Why is the queue age increasing?
• Evaluate: Can this product help without write access?

Those questions deserve different pages. Combining them into one broad article makes the answer harder to find and maintain.

Give each content type a contract

Product pages explain a durable capability and its trust boundary. Documentation helps someone complete a supported workflow. Field notes explain patterns and trade-offs. News records what changed.

A simple contract keeps the content types from competing:

• Product: what it does, who it is for, access required, and next step.
• Documentation: prerequisites, procedure, expected result, and recovery.
• Field note: problem, context, trade-offs, recommendation, and limits.
• News: change, reason, affected users, access status, and where to learn more.

Organize around systems, not service names alone

AWS services are important vocabulary, but a real workload usually combines several of them. A useful content cluster might center on “asynchronous order processing,” with supporting pieces for Lambda handlers, SQS retry behavior, Step Functions orchestration, DynamoDB idempotency, and observability.

This structure lets a service-specific article answer a narrow question while the system page shows how the pieces fit together.

Connect product content without forcing it

An article about mapping event sources can link naturally to Air. A production cost review can point to Hero. An architecture decision guide can introduce Xero.

The link should be a relevant next step, not a detour. If the product does not help with the workflow described in the article, it should not be inserted for the sake of conversion.

Review the map as the product changes

Content architecture is not a launch artifact. Product boundaries, supported AWS services, and developer questions change. Review the map when a capability ships, when support receives the same question repeatedly, or when two pages start answering the same intent.

The goal is straightforward: every important serverless workflow should have a clear home, a clear job, and a clear next step.