# Static Block Rendering with `content_for 'block'`

Two forms of `content_for` — pick the right one.

```liquid
{% comment %} Dynamic: render editor-managed blocks in order {% endcomment %}
{% content_for 'blocks' %}

{% comment %} Static: render a specific block by id + type {% endcomment %}
{% content_for 'block', type: 'announcement', id: 'top-bar' %}
```

Use **static** rendering when the block's position is fixed by the section (e.g. a header bar that always renders above the dynamic block stack) — the merchant can still edit its settings, but can't reorder or delete it.

```liquid
<div class="hero">
  {% content_for 'block', type: 'hero-eyebrow', id: 'eyebrow' %}
  {% content_for 'blocks' %}
  {% content_for 'block', type: 'hero-cta', id: 'cta' %}
</div>
```

## Static blocks require `{% doc %}`

Any block rendered via `content_for 'block'` **must** begin with a LiquidDoc header. The theme editor uses it to discover the block's parameters.

```liquid
{% doc %}
  Renders the hero call-to-action.

  @example
  {% content_for 'block', type: 'hero-cta', id: 'cta' %}
{% enddoc %}

<a class="btn" href="{{ block.settings.link }}">
  {{ block.settings.label }}
</a>

{% schema %}
{
  "name": "Hero CTA",
  "settings": [
    { "type": "text", "id": "label", "label": "Label", "default": "Shop now" },
    { "type": "url", "id": "link", "label": "Link" }
  ]
}
{% endschema %}
```

Dynamic blocks rendered via `content_for 'blocks'` don't require `{% doc %}`, but it's still recommended — see `liquid-doc-tags.md`.
