Adding meta tags to a SharePoint page means injecting a standards-aligned head block into a location SharePoint exposes for site-level or page-level HTML, then verifying that themes, page layouts, and any SEO web part have not duplicated or overwritten the tags you inserted. Modern SharePoint Online exposes only a small set of SEO properties natively — typically the site title, the site description, and the site logo — and the per-page properties panel does not let authors edit the HTML <head> directly, which is why contributors turn to classic-site workarounds, the SharePoint Framework, or property-bag-driven layouts as injection surfaces. Before worrying about where to place the markup, build a syntactically correct block first: the Meta Tag Generator produces exactly the kind of trimmed, escaped, UTF-8 head block that survives SharePoint master-page rendering without producing stray angle brackets, mismatched attribute quotes, or control characters that the platform sometimes inherits from pasted Office content. This article walks through the SharePoint-specific placement options, the duplicate-tag conflicts you will meet, and the verification steps that confirm the deployed source actually contains what you authored rather than what an editor silently rewrote.
What Meta Tags Mean Inside a SharePoint Page
A meta tag is a single HTML element that lives inside the document <head> and carries machine-readable information about the page that is not part of the visible body. The five elements that this generator emits — the UTF-8 charset declaration, the responsive viewport metadata, the <title> element, the description metadata, and an optional author metadata — represent the smallest standards-backed foundation a SharePoint page should ship with. The charset declaration tells the browser which character encoding to use for the entire document; the viewport metadata tells mobile browsers to match the device width without disabling user zoom; the title element is what browsers surface in tabs and bookmarks, and what search systems may reuse when assembling a result title; the description metadata offers a short page summary that compatible consumers can pick up; and the optional author element records a maintained byline name without claiming verified identity. The WHATWG HTML standard defines each of these elements and the contexts in which they belong, which matters in SharePoint because the platform often injects its own variants of the same elements through master pages and page layouts.
Why Native SharePoint SEO Settings Stop Short
SharePoint Online's built-in SEO settings cover the site-collection level — site title, site description, site logo, and a few search-engine directives — but they do not give per-page control over <title> or description on modern pages. The modern Page Properties panel accepts a page title and a hero summary, neither of which is rendered as a standards-compliant <title> element or <meta name="description"> tag, so search systems fall back to whatever SharePoint synthesizes. Classic SharePoint sites expose more levers — a Site Master Page that authors can edit in SharePoint Designer, a Script Editor web part that accepts raw HTML, and the SEOTitle-style fields surfaced by older publishing layouts — but each of these surfaces comes with its own gotchas: master-page edits can be overwritten by feature updates, and script editors are disabled in modern experiences. The shared limitation is that there is no single SharePoint UI knob for the basic five-element head block, so every team that wants clean title and description metadata ends up generating the block elsewhere and pasting it into a SharePoint-acceptable location.
Build a Clean Basic Head Block First
Before you start fighting SharePoint placement, generate the block you intend to paste. Open the Meta Tag Generator, enter one accurate document title, a concise page description, and an optional maintained author name, then copy the escaped output. The tool trims leading and trailing whitespace from every value, rejects control characters, encodes ampersands and angle brackets, and encodes attribute quotes where they could affect parsing. It limits the title to 200 characters, the description to 500, and the author to 120 — large enough that legitimate copy is never truncated, small enough that the block stays bounded. The viewport metadata is fixed to width=device-width, initial-scale=1, which preserves accessibility because the tool deliberately omits maximum-scale and user-scalable restrictions. The UTF-8 declaration is emitted before any textual metadata so that browsers do not have to re-parse the document when the encoding is announced later. Every input stays in the browser — nothing is sent to Lizely — which matters in SharePoint contexts where authors often work in restricted tenants and want a tool that does not require an outbound network call.
Reference: What the Generator Emits
The copied block is small by design and contains only the five elements below. None of these are decorative — each one maps to a documented behaviour in the WHATWG HTML specification, and SharePoint's own rendering pipeline interacts with them in specific ways.
| Element | Purpose | Value source | Bound | How SharePoint tends to interact with it |
|---|---|---|---|---|
| <meta charset="utf-8"> | Declares the document's character encoding for the browser parser | Fixed string | Always emitted | Master pages sometimes emit a second charset later in the head; the HTTP response header must not disagree |
| <meta name="viewport" content="width=device-width, initial-scale=1"> | Sets a responsive layout viewport that follows device width | Fixed string | Always emitted | Responsive web parts or mobile add-ins may inject their own viewport, which produces duplicates |
| <title> | Names the document; appears in browser tabs and bookmarks | Your title input | 200 characters | Page layouts routinely render their own title element from internal properties, which is the most common duplicate |
| <meta name="description"> | Short human-readable summary that compatible consumers may use | Your description input | 500 characters | SEO web parts and metadata-driven search layouts often add a second description tag |
| <meta name="author"> | Records a maintained byline name; optional | Your author input | 120 characters | Author metadata is rarely injected by SharePoint itself, so duplicates here usually come from a custom theme |
Canonical links, robots directives, Open Graph properties, and Twitter Card markup are deliberately excluded from this block. Each of those carries a separate decision and has a dedicated tool, and mixing every vocabulary into one form makes it easy to copy contradictory markup. Keep the copied block as one auditable unit, and handle any additional vocabulary elsewhere in the page or in a different generator.
Where and How to Add Meta Tags in SharePoint
Because SharePoint offers several injection surfaces rather than one obvious place, choosing the right surface for your environment is the most consequential decision. The following steps assume you have already generated a clean head block with the Meta Tag Generator and copied it to your clipboard.
- Identify your SharePoint experience. Confirm whether the target site is a modern SharePoint Online site, a classic publishing site, or a hybrid with both. Modern sites require SharePoint Framework (SPFx) extensions or property-bag-driven layouts; classic sites accept a Script Editor web part or a master-page edit; hybrid sites may need both paths.
- Choose an injection surface. For modern sites, deploy an SPFx application customizer that injects the head block via the shared UserCustomActions location, or store the values in the site property bag and render them through a search-driven layout. For classic sites, paste the block into a Script Editor web part placed inside a hidden web part zone or — for site-wide reach — add it to the site master page header.
- Paste the block exactly as copied. Open the chosen surface in edit mode, place the cursor inside the <head> region (for master pages and SPFx extensions) or inside the web part's HTML content area, and paste without reformatting. Do not paste it as visible body text, and do not run the pasted block through a "rich text" editor that escapes markup a second time.
- Save and publish through the right scope. Save the master page, check the SPFx extension in, or save the web part. For site-wide deployment, publish the master page as the active version; for per-page deployment, verify the SPFx customizer is scoped to the correct site collection.
- Note the title and description values you used. Record the exact strings you injected so you can search for them in the live source during verification, and so a future migration or feature update can be audited against the same baseline.
Verify the Deployed Source and Resolve Conflicts
After publishing, open the live page in a browser, view the page source, and confirm that the tags you injected actually appear in the delivered <head>. SharePoint themes, page layouts, and third-party SEO web parts frequently inject their own <title> element, their own description metadata, or a duplicate viewport, and the rendered source — not the editor preview — is what counts. Look for more than one <title> element, more than one <meta name="description">, conflicting charset declarations, or a Content-Type HTTP header that disagrees with the UTF-8 declaration. When a conflict appears, the resolution depends on the source: a theme-injected title usually requires editing the page layout or replacing the master page; a plugin-injected description usually requires the plugin's own settings panel; an SPFx conflict usually means two customizers are racing for the same UserCustomActions slot and one must be scoped away. Re-render the page after each fix and re-inspect. The block you pasted is a correct starting syntax, not a guarantee of indexing, ranking, or a specific search snippet — Google's title-link guidance explicitly notes that search systems can rewrite titles based on the page and the query.
Best Practices for SharePoint Meta Tags
Treat the title and description as content decisions, not syntax decisions. Write a title that names the page accurately rather than stuffing keywords; write a description that summarizes what a visitor will actually see rather than promising what the page does not deliver. Avoid duplicating descriptions across unrelated pages, because SharePoint's search and any external crawler will see those duplicates and treat them as low-value. Keep the author field populated only when the site maintains a meaningful value across pages; if author names vary per contributor, omit the field and rely on visible bylines plus appropriate structured data instead. Do not paste canonical link elements, robots directives, Open Graph properties, or Twitter Card markup into this block — those tags carry separate decisions and have dedicated generators, and mixing every vocabulary into one block is exactly how contradictory markup ends up in production. Finally, after every SharePoint feature update, master-page change, or theme upgrade, re-inspect the live source: SharePoint upgrades are a common silent source of duplicate tags, and a five-minute view-source check is cheaper than a week of unexplained search-result drift.
If you're weighing options, Create Facebook Graph Metadata With Open Graph Tags covers this in detail.