Meta Tag Checklist Before a Website Launch

Why metadata QA belongs in the launch plan

Metadata sits between your website and the systems that represent it elsewhere:

• Google uses titles, descriptions, canonical hints, robots directives, and structured data to understand pages.
• Social platforms use Open Graph and card tags to build link previews.
• Browsers, crawlers, and accessibility tools read page-level signals before anyone clicks a CTA.
• Internal teams use CMS fields to keep those signals current after launch.

A custom site can have strong design and still ship weak metadata if nobody owns the final QA pass. Template logic makes the problem bigger. One missing fallback can affect every blog post, resource page, landing page, or dynamic route.

Metadata QA costs little compared with a rebuild. Delay makes it expensive.

The short version: what to check

Use this table as the release gate before a new custom website, redesign, migration, or CMS rebuild goes live.

Start with the pages that affect revenue

Do not begin with every URL in the CMS. Start with the pages a buyer, search engine, or sales team will touch first:

• homepage
• service or solution pages
• pricing or plans pages
• demo, contact, and booking pages
• comparison pages
• high-intent blog posts
• case studies with approved proof
• resource pages used in nurture or sales follow-up
• legal, trust, and privacy pages

Then test the templates that generate long-tail pages. A single blog template can create hundreds of metadata mistakes. The same risk applies to CMS-driven landing pages, authors, categories, integrations, and gated resources.

Virdis treats metadata like a systems check because the work crosses strategy, content, design, development, and analytics. A title tag is copy. A canonical tag is architecture. An Open Graph image is brand control. A CMS fallback is maintainability.

Check title tags page by page

Every indexable page needs one clear title tag. It should name the page, match search intent, and fit the way a real buyer would scan a result.

Check these items before launch:

• Each priority page has a unique title.
• The title describes the actual page, not the template type.
• The brand appears where it helps, often at the end.
• The CMS cannot publish a blank title.
• Dynamic routes do not reuse the homepage title.
• Staging labels, internal notes, and placeholder copy are gone.

A good title tag is not a slogan. It tells the buyer and the crawler what the page is.

For example, “Custom Website Development for B2B SaaS | Virdis” does more work than “Solutions | Virdis.” The first title names the offer and audience. The second title asks the search result to carry dead weight.

Write descriptions for humans, not audits

Meta descriptions do not work as direct ranking levers. They still matter because they shape how a page appears in search and in many audit workflows.

Check that each priority page description:

• summarizes the page with concrete language
• matches the visible page content
• avoids internal positioning phrases that buyers would not search
• gives the reader a reason to click without hype
• stays current after the final content freeze

Skip empty promises. A description like “Learn how our team can help your business grow online” says nothing. Use the space to name the problem, audience, and next step.

For a service page, that might mean: “Custom website strategy, design, and development for B2B teams that need a faster, easier-to-manage marketing site.”

That sentence gives the buyer enough context to decide whether the page belongs in their short list.

Verify canonical tags on the production domain

Canonical tags tell search engines which URL represents the preferred version of a page. They matter most when a site has CMS routing, filters, campaign URLs, pagination, or migration history.

Before launch, check that every indexable page has one canonical tag and that it points to the final production URL.

Watch for these mistakes:

• canonicals pointing to staging or preview domains
• HTTP canonicals on an HTTPS site
• trailing slash mismatches that conflict with redirects
• every dynamic page pointing back to the homepage
• paginated, filtered, or parameterized pages pointing to the wrong parent
• blog posts using category URLs as canonicals

Canonical QA needs real production URLs. A local environment can tell you whether a component renders. It cannot prove the final domain, redirects, and CMS data agree.

Remove accidental noindex rules

Staging sites often use noindex or robots rules to stay out of search. Good. Trouble starts when those rules ship with production.

Check for robots directives in three places:

• page-level meta robots tags
• X-Robots-Tag HTTP headers
• robots.txt rules that block important paths or assets

Google documents robots meta tags and X-Robots-Tag headers as ways to control indexing and serving snippets. That control cuts both ways. The wrong directive can hide a launch page that your team expects to rank.

For production, confirm that priority pages do not include noindex, nofollow, or restrictive snippet directives unless you mean it. Also confirm that private or thin pages use the right control. Robots.txt alone does not keep a URL private.

Test Open Graph previews before the announcement

Open Graph tags control how a page appears when someone shares it across many platforms and messaging tools. At minimum, priority pages need:

• og:title
• og:description
• og:image
• og:url
• og:type
• og:sitename

The preview should look intentional on LinkedIn, Slack, iMessage, and any sales channel your team uses. That means the image loads, the crop works, the title is specific, and the description does not pull random body copy.

Open Graph QA catches brand problems that normal browser QA misses. A homepage can look polished while its link preview shows a stretched logo, a cropped hero image, or a page title from two months ago.

Use production URLs for this test. Some platforms cache previews, so test before launch and force a refresh where the platform allows it.

Set X card tags without building a separate content system

X card tags can share the same strategic content as Open Graph. The goal is consistency, not a second parallel metadata workflow.

Check:

• twitter:card uses the right card type
• twitter:title matches the page title or adapts it with care
• twitter:description matches the page promise
• twitter:image uses a valid, public image
• image dimensions and file size work for card previews

If the site uses fallback logic, document it. For most teams, Open Graph fields should serve as the primary CMS fields, with X card tags inheriting those values unless a specific override exists.

That approach protects maintainability. Your content team should not update the same idea in four places to publish one page.

Validate structured data against visible content

Structured data helps search engines understand content types. It can also create risk when teams add schema for things the page does not show.

Before launch, check schema for:

• Organization on the site or relevant global layout
• WebSite where search action or site identity applies
• BreadcrumbList on pages with visible breadcrumbs
• Article on blog posts and editorial content
• FAQPage when the page has a real FAQ section
• Product, SoftwareApplication, or Review when the content supports it

Do not use schema to decorate weak content. If the FAQ section is not visible on the page, do not ship FAQ schema. If a page does not include approved reviews, do not add review schema. If a case study lacks approved public proof, keep the claims qualitative.

Good schema describes the page. Bad schema asks search engines to believe the page is more useful than it is.

Build metadata fields your team can maintain

Metadata QA needs a CMS your team can trust after launch.

For each content type, check that editors can control:

• SEO title
• meta description
• canonical URL behavior where needed
• social title
• social description
• social image
• noindex setting for intentional exclusions
• schema fields where the schema type makes sense

Then check fallbacks. A blog post without a custom social title might use the article title. A missing social description might use the excerpt. A missing image might use a branded default when that default fits the content.

Fallbacks should prevent broken output without hiding editorial gaps. The CMS can protect the team from blank fields. It should not make vague metadata feel finished.

Run metadata QA after the content freeze

Metadata changes during the last week before launch. Page names change. URLs change. Images change. Someone rewrites the hero. The final QA pass needs to happen after the content freeze and before the deploy.

Use a simple workflow:

1. Export or crawl the production candidate URLs.
2. Check metadata fields in the rendered HTML and in the CMS.
3. Validate titles, descriptions, canonicals, robots directives, OG tags, and schema.
4. Open a sample of pages in social preview tools.
5. Fix templates first, then individual pages.
6. Retest the same URL set after fixes.

If the issue appears on more than one page, assume it is a system problem until proven otherwise.

Common mistakes to catch before launch

These are the metadata failures that show up most often in custom website QA:

• homepage title reused across the whole site
• meta descriptions copied from old pages during migration
• social images missing on blog posts
• Open Graph URLs pointing to staging
• canonical tags fighting redirects
• noindex left on service pages
• schema added without matching visible content
• CMS fields that let editors publish blank metadata
• preview cards cached with old launch copy
• legal pages indexed with draft titles

None of these problems requires a strategy retreat. They need ownership, a checklist, and enough discipline to test the rendered site instead of the intent in the project brief.

A practical pre-launch metadata checklist

Use this before the site moves from approved to launched.

Page-level checks

• Open the rendered production URL.
• Confirm one title tag exists.
• Confirm one meta description exists where the page needs one.
• Confirm one canonical tag points to the preferred production URL.
• Confirm robots directives match the indexation plan.
• Confirm the page does not reference staging domains in metadata.

Social preview checks

• Confirm Open Graph title and description match the page.
• Confirm the Open Graph image loads from a public URL.
• Confirm the image crop works in common preview sizes.
• Confirm X card tags inherit clean fallbacks or explicit values.
• Confirm shared links do not show placeholder copy.

Structured data checks

• Confirm schema matches visible content.
• Confirm Article schema appears on editorial content where useful.
• Confirm FAQ schema appears with a visible FAQ section.
• Confirm Organization and breadcrumb data use correct names and URLs.
• Confirm your team fixes validation errors before launch.

CMS checks

• Confirm required metadata fields have helpful labels.
• Confirm editors can preview metadata before publishing.
• Confirm fallback logic produces safe output.
• Confirm no content type depends on developer edits for routine metadata changes.
• Confirm ownership for post-launch updates.

How Virdis handles metadata in custom builds

For Virdis, metadata is not a plugin checkbox. It is part of the custom website system.

The right setup depends on the site, but the standard is consistent: strategic page planning, clean CMS fields, durable templates, production-domain QA, and a launch process that catches metadata issues before buyers do.

That matters for teams that plan to keep using the website after launch. A site that needs a developer for every title, description, or social preview will drift. A site with clean fields and sane fallbacks can keep pace with campaigns, product changes, and sales priorities.

Frequently asked questions

When should metadata QA happen during a website launch?

Run a first pass when developers finish templates, then run the final pass after content freeze on the production candidate domain. The final pass matters because URLs, page names, and social images often change late.

Are meta descriptions still worth writing?

Yes. They do not act as a direct ranking lever, but they influence search snippets, audit quality, and how teams understand the page. Priority pages should have clear descriptions written for buyers.

Should every page have Open Graph tags?

Every shareable page should have Open Graph tags. At minimum, priority pages, blog posts, landing pages, and sales-linked resources need clean titles, descriptions, images, URLs, and page types.

Can a plugin handle metadata?

A plugin can expose fields. It cannot decide page intent, write useful copy, fix bad CMS fallbacks, or align canonicals with redirects. Custom sites need metadata logic that fits the site architecture.

Should every blog post include FAQ schema?

No. Add FAQ schema when the page has a visible FAQ section with useful questions and answers. Schema should describe the page, not inflate it.