mlz preflight: Check SSL, OG Tags, and UTM Parameters in One Command

The three-tool problem

Before publishing a campaign link, a thorough pre-launch check requires confirming three distinct things about the destination URL:

SSL and URL health

Is the destination reachable? Does it respond with HTTPS? Does it redirect correctly without stripping query parameters? This is the basic "does the link work" check — but it's often skipped entirely because it requires running curl -L -v and reading through verbose output.

Open Graph tags

When the campaign link is shared on LinkedIn, Facebook, or X, does the platform render a rich preview? Missing og:image or og:title means the post shows as a bare URL with no visual context — the fastest way to tank click-through rate before the campaign even launches.

UTM parameter integrity

Are the UTM parameters valid? Will they survive the full redirect chain to the final destination? A link with utm_source=LinkedIn (capital L) fragments your GA4 data against every other LinkedIn campaign you've ever run.

Checking all three manually means three separate tools and three separate steps: a URL validator (or browser DevTools), the Facebook Sharing Debugger or mlz inspect, and manual review of the UTM parameters in the built link. For a single campaign, that's maybe five minutes. For a team running ten campaigns a week, it's a process that gets skipped.

mlz preflight is the answer to that gap. One command, all three categories, one ready flag.

Category 1: SSL and destination checks

The first set of checks confirms the URL is reachable and technically valid before any campaign budget is spent sending traffic to it. These are the checks in the campaign link validation guide's "URL health" category:

url_format

Is the URL syntactically valid? Catches typos, missing protocols, and malformed query strings before the HTTP request is even sent.

ssl

Does the URL use HTTPS? A campaign link pointing to an http:// destination triggers browser security warnings, breaks ad platform tracking in some configurations, and fails most platform review processes. This check catches mixed-content issues silently overlooked during URL construction.

resolution

Does the destination respond with a 200 status code? A 404, 301 without a final destination, or a server timeout will all fail here. Catching a broken destination before launch means catching it before it burns impressions.

redirects

How many redirect hops does the URL follow? mlz preflight follows the complete chain and reports the hop count. Two or more hops triggers a warning — worth investigating even when parameters survive, since each hop adds latency and risk.

utm_preserved

Do UTM parameters survive every redirect hop? This is the check that catches redirect-based UTM stripping — the silent attribution killer that sends campaigns to "direct (none)" in GA4.

response_time

How long does the destination take to respond? Slow landing pages hurt Quality Score in paid search and increase bounce rate. The check warns if the page loads in over 2 seconds.

Category 2: Open Graph and social preview checks

The second set of checks confirms the destination will render correctly when the campaign link is shared on social platforms. These are the same checks run by the Facebook Sharing Debugger and the LinkedIn Post Inspector — but without the browser and without the manual step. The preflight check guide covers why these matter for campaign performance.

og_tags

Are og:title, og:description, and og:image all present? A missing og:image means no visual preview on any social platform. Missing og:title means the platform falls back to the raw <title> tag — which is often a generic site title rather than a campaign-specific headline.

twitter_card

Is a twitter:card meta tag present and set to a valid type? Without it, X (Twitter) renders a bare URL link with no preview image, no title, and no description. The check also reports the card type so you can confirm it's summary_large_image for maximum visual real estate.

viewport

Is a <meta name="viewport"> tag present? This confirms the page is responsive. LinkedIn and Facebook will render the page in a mobile frame for the social preview screenshot — a non-responsive page produces a distorted or zoomed-out preview image.

canonical

Does the page have a canonical URL? Canonical tags affect how social platforms deduplicate shared content and how search engines attribute the page. A missing or mismatched canonical on a campaign landing page can cause attribution issues down the line.

favicon

Is a favicon present? Some social platforms include the favicon in their preview cards. More importantly, a missing favicon is a signal that the landing page wasn't fully prepared before launch.

Category 3: UTM parameter checks

The third set of checks validates the UTM parameters themselves — not just that they exist, but that they conform to best practices for reliable attribution. This is the check category that most validation tools skip entirely because they're not purpose-built for campaign link infrastructure.

utm_format

Are the UTM parameter values lowercase and hyphen-separated? GA4 treats utm_source=LinkedIn and utm_source=linkedin as two different traffic sources. mlz preflight enforces the naming conventions from the UTM naming convention guide and flags any values that deviate.

utm_conflicts

Does the destination URL already have UTM parameters appended? A destination with ?utm_source=google hardcoded will cause the new parameters to conflict or override, depending on how analytics processes the first vs. last occurrence. This check catches duplicate parameter situations before they corrupt your attribution data.

utm_preserved (redirect check)

This check runs across both the SSL/destination category and the UTM category: it verifies that the parameters you set survive every hop in the redirect chain. It reports specifically which parameters were preserved or lost at each hop, so you can pinpoint exactly where stripping occurs.

The combined output means you never have to cross-reference a URL validator, a social preview checker, and a UTM parameter review in separate tools. Every check runs in a single pass against the same destination URL.

The unified output: one ready flag

What makes mlz preflight useful for automated workflows — CI/CD pipelines, GitHub Actions, AI agents — is not just that it runs multiple checks. It's that it aggregates all checks into a single top-level ready boolean and a summary object. Any failure in any category sets ready: false.

ready:        true
tracked_url:  https://example.com/landing?utm_source=linkedin&utm_medium=social&utm_campaign=q2-launch

checks:
  PASS  ssl              URL uses HTTPS.
  PASS  resolution       Destination responded with 200 (187ms).
  PASS  redirects        No redirect chain detected.
  PASS  utm_preserved    All UTM parameters present at destination.
  PASS  og_tags          og:title, og:description, og:image present.
  PASS  twitter_card     summary_large_image configured.
  PASS  viewport         Mobile viewport meta tag present.
  PASS  response_time    Page loaded in 187ms.

summary:      8 passed, 0 warnings, 0 failed
verdict:      All checks passed. Campaign link is ready to publish.

When something fails, the output identifies the failing check category precisely. Here's what a failed OG check looks like alongside passing SSL and UTM checks — the same unified output, different result:

ready:        false
tracked_url:  https://example.com/landing?utm_source=linkedin&utm_medium=social&utm_campaign=q2-launch

checks:
  PASS  ssl              URL uses HTTPS.
  PASS  resolution       Destination responded with 200.
  PASS  redirects        No redirect chain detected.
  PASS  utm_preserved    All UTM parameters present at destination.
  FAIL  og_tags          og:image is missing. Social previews will render without an image.
  PASS  twitter_card     summary_large_image configured.
  PASS  viewport         Mobile viewport meta tag present.
  PASS  response_time    Page loaded in 210ms.

summary:      7 passed, 0 warnings, 1 failed
verdict:      Do not publish. Add og:image before launching this campaign.

Because the failure is specific — og:image is missing not "something went wrong" — the fix is unambiguous. Add the og:image meta tag to the landing page, re-run mlz preflight, confirm ready: true, then publish.

Structured JSON output for pipelines and agents

For CI/CD pipeline integration, pass --format json to get structured output you can parse with jq or any language. The shape is consistent whether the check passes or fails:

{
  "ready": true,
  "tracked_url": "https://example.com/landing?utm_source=linkedin&utm_medium=social&utm_campaign=q2-launch",
  "checks": [
    { "check": "ssl", "status": "pass", "message": "URL uses HTTPS." },
    { "check": "resolution", "status": "pass", "message": "Destination responded with 200." },
    { "check": "redirects", "status": "pass", "message": "No redirect chain detected." },
    { "check": "utm_preserved", "status": "pass", "message": "All UTM parameters present at destination." },
    { "check": "og_tags", "status": "pass", "message": "og:title, og:description, og:image present." },
    { "check": "twitter_card", "status": "pass", "message": "summary_large_image configured." }
  ],
  "summary": {
    "total": 8, "passed": 8, "warnings": 0, "failed": 0
  },
  "recommendation": "All checks passed. Campaign link is ready to publish."
}

In a GitHub Actions workflow, gating on the ready flag is a single jq call:

$ result=$(mlz preflight --url "$URL" --source linkedin --medium social --campaign q2 --format json)
$ ready=$(echo "$result" | jq -r '.ready')
$ if [ "$ready" != "true" ]; then echo "Preflight failed — aborting deploy" && exit 1; fi

For AI agents using the MCP interface, the same data comes back as a tool call response. The agent reads ready and either proceeds to publish or stops and reports the failing checks to the user. No parsing, no ambiguity — just a boolean and a list of reasons.

Why other tools don't check all three

The gap exists because SSL validators, OG tag checkers, and UTM builders have historically been built by different teams for different purposes:

Google Campaign URL Builder

Builds UTM links in a web form. No SSL check, no OG tag check, no validation of any kind. The link it produces may point to a broken destination or a page with no social preview — you won't know until you test it manually.

Facebook Sharing Debugger / LinkedIn Post Inspector

Check OG tags for a specific URL. No UTM parameter awareness, no SSL check, no redirect chain analysis. Both require a browser session and manual input for every URL.

SSL Labs / SSL checker tools

Check SSL certificate validity and configuration depth. No OG tags, no UTM parameters, no redirect chain awareness beyond basic chain following.

UTM validators

Validate UTM parameter format in isolation. No destination check, no SSL verification, no OG tag inspection. They confirm the parameters are well-formed but not that the destination they point to is ready.

The mlz preflight vs. other tools comparison covers the full gap analysis. The short version: none of these tools were designed to answer the campaign-launch question, which is not "is the SSL valid in isolation?" or "do the OG tags parse?" — it's "is this specific URL ready to receive paid traffic right now?"

mlz preflight answers that question.

Related reading

FAQ

Does mlz preflight require an API key?

No. The preflight check runs without an API key for the SSL, OG tag, and UTM validation categories. An API key is required to store the generated link and campaign record. Run mlz auth register --email [email protected] to get a free key (50 links/month on the free tier), or use the tool without a key for pure validation.

Can I run mlz preflight without building a UTM link?

Use mlz check to validate SSL, resolution, and redirects for any URL without building a tracked link. Use mlz inspect to check OG tags and social preview readiness independently. mlz preflight combines both into a single call and also builds the tracked UTM link.

What does "ready: false" mean for warnings vs. failures?

Only failures set ready: false. Warnings leave ready: true but flag items worth reviewing before launch — for example, a redirect chain with two hops that preserves all UTM parameters is a warning, not a failure. The distinction gives teams flexibility to proceed with awareness rather than requiring a perfect score for every check.

Can I use mlz preflight in an AI agent workflow?

Yes. When connected via MCP, the mlz_preflight tool is available to Claude Code, Cursor, and other MCP-compatible agents. The agent calls the tool with the campaign parameters, reads the ready flag and checks array in the response, and decides whether to proceed. No browser, no manual steps.

How does mlz preflight compare to running mlz check and mlz inspect separately?

mlz check covers SSL, resolution, redirects, and response time. mlz inspect covers OG tags, Twitter Card, viewport, canonical, and favicon. mlz preflight combines both, adds UTM parameter building and validation, and returns a unified ready verdict. Running them separately gives you the same information in two steps — preflight gives you everything in one.