Stay organized with collections
Save and categorize content based on your preferences.
Use sentence case for headings and titles. Use descriptive headings and titles because they help
a reader navigate their browser and the page. It's easier to jump between pages and sections of a
page if the headings and titles are unique.
Heading and title text
Write document titles based on the primary purpose of the document. If a
document is primarily a tutorial, but it has a conceptual introduction, write a
task-based title. Write section headings based on the type of content that's in
the section.
Guidance
Recommended
Not recommended
For a task-based heading, start with a
bare infinitive,
also known as a plain form or
base form
verb. In English, the imperative mood also uses the base form verb,
so it looks the same as the bare infinitive.
Task-based headings are frequently used in quickstarts, how-to
documents, and tutorials.
Create an instance
Creating an instance
For a conceptual or non-task-based heading, use a
noun phrase that
doesn't start with an -ing verb.
Noun-phrase headings are frequently used in concept documentation.
Migration to Google Cloud
Migrating to Google Cloud
Use a unique level-1 heading (h1) for each page in a set of documents and only use
a level-1 heading once on a page.
It's OK to use task-based and conceptual heading styles in the same document.
If a single document includes both task-based and conceptual sections, then use
the appropriate phrasing for each section's heading.
When possible, avoid using -ing verb forms as the first word in any heading or
title.
Recommended:
Transfer data sets
Not recommended:
Transferring data sets
An -ing verb form is a present participle or gerund. These verb forms
are inconsistently translated when they're used as the first word in a title,
and they increase character count in limited spaces.
Sometimes, there might not be a better alternative to using a gerund, such as the following
examples:
Billing
Pricing
It's OK to use a gerund in these cases.
It's OK to use an -ing verb form later in a heading or title, such as
Introduction to BigQuery monitoring.
Avoid repeating the exact page title in a heading on the page if possible.
For example, if you're documenting how to create a virtual machine and how to start a virtual
machine on the same task-based page, the page title could be Create and start VM instances,
with section headings Create a VM and Start a VM.
Example headings
The following example is a task-based document that includes a conceptual
heading and a task-based heading.
Don't include numbers in headings to indicate a sequence of sections.
Use punctuation in headings sparingly, if at all. Punctuation can be a sign that your heading is
too complicated. Consider rewriting.
Only use an abbreviation of a word in a page title or heading if it's the more commonly known
version of the word. If you do use an abbreviation in the page title or heading, the first
instance of the word in a paragraph needs to be defined.
You can define the abbreviation in the page title or heading, but consider if the additional
length adds value.
For SEO, use the more prominent version of the term in headings. For more information, see
Abbreviations.
In general, guidance that applies to text also applies to headings—for example,
contractions and articles.
Avoid using code items in headings when possible. If you must mention a code item in a heading,
add a descriptive noun to the item in code font. For more information, see
Grammatical treatment of code elements.
Use heading tags to structure your content hierarchically—for example,
<h1>, <h2>, and <h3> in HTML, or
#, ##, and ### in Markdown.
To change the visual formatting of a heading, use CSS rather than using a heading level that
doesn't fit the hierarchy. Don't make up your own formatting for headings.
Don't put a link in a heading because it can easily be confused as a style applied to a heading
instead of a link.
Use a heading hierarchy and take the following items under consideration:
Ensure that each page in your project includes a unique level-1 heading. In some publishing systems, a
level-1 heading might be generated automatically based on a page title that you supply.
Don't skip levels of the heading hierarchy. For example, put an <h3> tag
only under an <h2> tag.
If you're introducing a group of related H3 or lower sections within a larger H2 section, use the
phrase the following sections. Don't refer to the group of sections using the phrases
this section or these sections because those phrases are ambiguous.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-04-10 UTC."],[[["\u003cp\u003eUse sentence case for all headings and titles to improve readability and navigation.\u003c/p\u003e\n"],["\u003cp\u003eStructure content with descriptive headings that reflect the type of content (task-based or conceptual) using bare infinitives for tasks and noun phrases for concepts.\u003c/p\u003e\n"],["\u003cp\u003eOrganize content hierarchically with heading tags (h1, h2, h3, etc.) and ensure each page has a unique h1 heading; avoid skipping heading levels or using empty headings.\u003c/p\u003e\n"],["\u003cp\u003eAvoid using "-ing" verbs, numbers, and excessive punctuation in headings; if an abbreviation is used, define it in the first paragraph following the heading.\u003c/p\u003e\n"],["\u003cp\u003eWhen summarizing subheadings, use the phrase "in the following sections" to clearly connect the content.\u003c/p\u003e\n"]]],["Document titles should reflect the primary purpose, often task-based with a bare infinitive verb. Section headings should be content-specific, using noun phrases for conceptual content and bare infinitives for tasks. Avoid starting headings with \"-ing\" verbs, except in specific cases like \"Billing\" or \"Pricing.\" Use unique level-1 headings per page and follow a hierarchical structure without skipping levels. Refrain from numbers or excessive punctuation in headings and use \"in the following sections\" when introducing subheadings.\n"],null,["# Headings and titles\n\nUse sentence case for headings and titles. Use descriptive headings and titles because they help\na reader navigate their browser and the page. It's easier to jump between pages and sections of a\npage if the headings and titles are unique.\n\nHeading and title text\n----------------------\n\nWrite document titles based on the primary purpose of the document. If a\ndocument is primarily a tutorial, but it has a conceptual introduction, write a\ntask-based title. Write section headings based on the type of content that's in\nthe section.\n\n| Guidance | Recommended | Not recommended |\n|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------|---------------------------|\n| For a task-based heading, start with a [*bare infinitive*](https://wikipedia.org/wiki/Infinitive#English), also known as a *plain form* or [*base form*](https://wikipedia.org/wiki/English_verbs#Base_form) verb. In English, the *imperative mood* also uses the base form verb, so it looks the same as the bare infinitive. Task-based headings are frequently used in quickstarts, how-to documents, and tutorials. | Create an instance | Creating an instance |\n| For a conceptual or non-task-based heading, use a [*noun phrase*](https://wikipedia.org/wiki/Noun_phrase) that doesn't start with an *-ing* verb. Noun-phrase headings are frequently used in concept documentation. | Migration to Google Cloud | Migrating to Google Cloud |\n\nUse a unique level-1 heading (`h1`) for each page in a set of documents and only use\na level-1 heading once on a page.\n\nIt's OK to use task-based and conceptual heading styles in the same document.\nIf a single document includes both task-based and conceptual sections, then use\nthe appropriate phrasing for each section's heading.\n\nWhen possible, avoid using *-ing* verb forms as the first word in any heading or\ntitle.\n\nRecommended:\nTransfer data sets\n\nNot recommended:\nTransferring data sets\n\nAn *-ing* verb form is a present participle or gerund. These verb forms\nare inconsistently translated when they're used as the first word in a title,\nand they increase character count in limited spaces.\n\nSometimes, there might not be a better alternative to using a gerund, such as the following\nexamples:\n\n- Billing\n- Pricing\n\nIt's OK to use a gerund in these cases.\n\nIt's OK to use an *-ing* verb form later in a heading or title, such as\n*Introduction to BigQuery monitoring*.\n\nAvoid repeating the exact page title in a heading on the page if possible.\nFor example, if you're documenting how to create a virtual machine and how to start a virtual\nmachine on the same task-based page, the page title could be *Create and start VM instances* ,\nwith section headings *Create a VM* and *Start a VM*.\n\n### Example headings\n\nThe following example is a task-based document that includes a conceptual\nheading and a task-based heading.\n\nRecommended:\n\n### HTML\n\n```\n\u003ch1\u003eLog serving requests by using AI Platform Prediction\u003c/h1\u003e\n\n\u003cp\u003eThis task-based document shows how to monitor machine learning models. The\ndocument title starts with a bare infinitive.\u003c/p\u003e\n\n\u003ch2\u003eML model monitoring overview\u003c/h2\u003e\n\n\u003cp\u003eThis section provides a conceptual overview of ML model monitoring. Its title is\na noun phrase.\u003c/p\u003e\n\n\u003ch2\u003eConfigure notebook settings\u003ch2\u003e\n\n\u003cp\u003eThis task-based section provides a series of steps to set variables in a\nnotebook. Its title starts with a bare infinitive.\u003c/p\u003e\n```\n\n### Markdown\n\n```\n# Log serving requests by using AI Platform Prediction\n\nThis task-based document shows how to monitor machine learning models. The\ndocument title starts with a bare infinitive.\n\n## ML model monitoring overview\n\nThis section provides a conceptual overview of ML model monitoring. Its title is\na noun phrase.\n\n## Configure notebook settings\n\nThis task-based section provides a series of steps to set variables in a\nnotebook. Its title starts with a bare infinitive.\n\n```\n\nHeading and title format\n------------------------\n\n- Use sentence case for headings and titles. For more information, see [Capitalization in titles and\n headings](/style/capitalization#capitalization-in-titles-and-headings).\n- Don't include numbers in headings to indicate a sequence of sections.\n- Use punctuation in headings sparingly, if at all. Punctuation can be a sign that your heading is too complicated. Consider rewriting.\n- Only use an abbreviation of a word in a page title or heading if it's the more commonly known version of the word. If you do use an abbreviation in the page title or heading, the first instance of the word in a paragraph needs to be defined. You can define the abbreviation in the page title or heading, but consider if the additional length adds value. For SEO, use the more prominent version of the term in headings. For more information, see [Abbreviations](/style/abbreviations).\n- In general, guidance that applies to text also applies to headings---for example, [contractions](/style/contractions) and [articles](/style/articles).\n- Avoid using code items in headings when possible. If you must mention a code item in a heading, add a descriptive noun to the item in code font. For more information, see [Grammatical treatment of code elements](/style/code-in-text#grammatical-treatment-of-code-elements).\n- Use heading tags to structure your content hierarchically---for example, `\u003ch1\u003e`, `\u003ch2\u003e`, and `\u003ch3\u003e` in HTML, or `#`, `##`, and `###` in Markdown.\n- Use API levels for [Android\n versions](/style/product-names#android-versions).\n- To change the visual formatting of a heading, use CSS rather than using a heading level that doesn't fit the hierarchy. Don't make up your own formatting for headings.\n- Don't put a link in a heading because it can easily be confused as a style applied to a heading instead of a link.\n- Use a heading hierarchy and take the following items under consideration:\n - Ensure that each page in your project includes a unique level-1 heading. In some publishing systems, a level-1 heading might be generated automatically based on a page title that you supply.\n - Don't skip levels of the heading hierarchy. For example, put an `\u003ch3\u003e` tag\n only under an `\u003ch2\u003e` tag.\n\n Recommended:\n\n ### HTML\n\n ```\n \u003ch1\u003eTransfer data sets\u003c/h1\u003e\n\n \u003cp\u003eThis document provides a high-level overview of ways to transfer your data to Google\n Cloud.\u003c/p\u003e\n\n \u003ch2\u003eEstimate costs\u003c/h2\u003e\n ```\n\n ### Markdown\n\n ```\n # Transfer data sets\n\n This document provides a high-level overview of ways to transfer your data to Google Cloud.\n\n ## Estimate costs\n ```\n\n Not recommended:\n\n ### HTML\n\n ```\n \u003ch1\u003eTransfer data sets\u003c/h1\u003e\n\n \u003cp\u003eThis document provides a high-level overview of ways to transfer your data to Google\n Cloud.\u003c/p\u003e\n\n \u003ch3\u003eEstimate costs\u003c/h3\u003e\n ```\n\n ### Markdown\n\n ```\n # Transfer data sets\n\n This document provides a high-level overview of ways to transfer your data to Google Cloud.\n\n ### Estimate costs\n ```\n - Don't use empty headings or headings with no associated content.\n\n Recommended:\n\n ### HTML\n\n ```\n \u003ch2\u003eMigrate VMs to Compute Engine\u003c/h2\u003e\n\n \u003cp\u003eMigration is not just a single step. The following sections describe the recommended\n steps.\u003c/p\u003e\n\n \u003ch3\u003eDesign the migration\u003c/h3\u003e\n ```\n\n ### Markdown\n\n ```\n ## Migrate VMs to Compute Engine\n\n Migration is not just a single step. The following sections describe the recommended steps.\n\n ### Design the migration\n ```\n\n Not recommended:\n\n ### HTML\n\n ```\n \u003ch2\u003eMigrate VMs to Compute Engine\u003c/h2\u003e\n\n \u003ch3\u003eDesign the migration\u003c/h3\u003e\n ```\n\n ### Markdown\n\n ```\n ## Migrate VMs to Compute Engine\n\n ### Design the migration\n ```\n\nRefer to a group of sections\n----------------------------\n\nIf you're introducing a group of related H3 or lower sections within a larger H2 section, use the\nphrase *the following sections* . Don't refer to the group of sections using the phrases\n*this section* or *these sections* because those phrases are ambiguous.\n\nRecommended:\n\n### HTML\n\n```\n\u003ch2\u003eViews in the data preparation editor\u003c/h2\u003e\n\n\u003cp\u003eThe following sections describe the views in the data preparation editor.\u003c/p\u003e\n\n\u003ch3\u003eData view\u003c/h3\u003e\n\n\u003cp\u003e...\u003c/p\u003e\n\n\u003ch3\u003eGraph view\u003c/h3\u003e\n\n\u003cp\u003e...\u003c/p\u003e\n\n\u003ch3\u003eSchema view\u003c/h3\u003e\n\n\u003cp\u003e...\u003c/p\u003e\n```\n\n### Markdown\n\n```\n## Views in the data preparation editor\n\nThe following sections describe the views in the data preparation editor.\n\n### Data view\n\n...\n\n### Graph view\n\n...\n\n### Schema view\n\n...\n```"]]