How mlz preflight Catches What Other Tools Miss

What mlz preflight actually checks

Before comparing tools, you need to know what a complete campaign link validation looks like. mlz preflight is a single command that combines link building and validation. It runs these checks every time:

UTM link construction

Builds the tracked URL from your parameters with consistent, lowercase formatting. Enforces naming conventions so utm_source=LinkedIn and utm_source=linkedin don't fragment your analytics into separate rows.

SSL / HTTPS

Confirms the destination uses HTTPS. HTTP destinations trigger "Not Secure" browser warnings that erode user trust before a visitor reads a single word of your landing page.

HTTP resolution

Sends a request to the destination and verifies a 200 OK response. Catches 404 errors, misconfigured domains, and servers that are down entirely — before your paid traffic hits them.

Redirect chain

Follows every hop from the initial URL to the final destination. Multi-hop redirect chains slow page loads and can strip UTM parameters in transit. A link that redirects three times before landing is a broken attribution risk.

Response time

Measures how long the page takes to respond. Pages slower than 1.5 seconds get a warning; pages over 3 seconds fail. Every extra second costs roughly 7% in conversions on paid traffic.

Open Graph tags

Checks for og:title, og:description, and og:image. These control the preview card when your link is shared on LinkedIn, Facebook, Slack, and most messaging platforms. A missing og:image means a blank rectangle instead of a compelling preview.

Twitter Card tags

Checks for twitter:card and related meta tags. X (Twitter) uses its own card system separate from OG. Without Twitter Card tags, your link renders as plain text in the feed.

Viewport

Confirms a <meta name="viewport"> tag is present. Pages without it render at desktop width on mobile devices, which is unreadable and drives up bounce rates on mobile-sourced traffic.

Canonical URL

Compares the page's <link rel="canonical"> against the destination URL. A mismatch splits your analytics data across two URL paths.

Favicon

Verifies a favicon is present. A small signal for credibility — missing favicons make landing pages look unfinished in browser tabs.

UTM parameter preservation

Follows the redirect chain with UTM parameters attached and confirms they survive to the final destination. This is the check that catches silent attribution failure — the redirect strips your parameters and the visit records as "direct" in Google Analytics.

All of these run in a single command and return structured JSON. The ready field at the top level tells you whether the link is safe to publish. For the full walkthrough, see why every campaign link needs a preflight check.

What Google's Campaign URL Builder doesn't check

Google's Campaign URL Builder (the web form at ga.google.com/analytics/...) is the default UTM building tool for most marketing teams. It's free, it's widely known, and it solves exactly one problem: concatenating a destination URL with UTM parameters into a tracked link.

That's it. The tool generates the URL and stops there. It doesn't request the destination. It doesn't check the SSL certificate. It doesn't follow any redirect chain. It doesn't inspect meta tags. It has no CLI, no API, and no structured output — it's a web form that produces a string.

The result is that every link generated by the Campaign URL Builder is an untested link. Teams that use it exclusively are publishing on faith: the link looks right, so it probably works. Sometimes it doesn't. The destination 404s. The redirect strips the UTMs. The landing page has no OG image. The team finds out after the campaign has spent budget.

What UTM.io and UTM Mind don't check

UTM.io and similar dashboard tools (UTM Mind, Terminus, etc.) extend the Campaign URL Builder concept with team collaboration, link organization, and template-based naming. These are real improvements over a bare web form. But validation is still largely absent from their core workflow.

UTM.io can store your naming conventions and enforce them when you build a link. What it can't do is tell you whether the destination URL actually resolves, whether the page loads in under three seconds, or whether the landing page has the Open Graph tags needed to render a preview card on LinkedIn.

The dashboard paradigm has a structural limit: it's designed for humans looking at a browser. That means no CLI, no API for programmatic use, and no MCP interface for AI agents. If you want to check a hundred links in a CI/CD pipeline before a campaign launch, UTM.io gives you no path to do it.

What manual QA misses

Some teams do manual validation: open the link in a browser, confirm it loads, paste it into the LinkedIn post inspector, check the preview. This is better than nothing. But manual QA has three problems that compound each other at scale.

First, it doesn't catch parameter stripping. A human clicking a link sees the final destination page — but they don't see whether the UTM parameters survived the redirect chain. The only way to verify parameter preservation is to inspect the final URL's query string, which most testers don't do.

Second, it doesn't scale. A campaign with 10 platform-specific links takes 10 manual checks, each taking several minutes. A campaign with 50 links is effectively unchecked because no team has time to do it properly. Automation doesn't have this problem.

Third, it's unreliable. The LinkedIn post inspector caches previews. Browser extensions intercept redirects. Local caches mask slow page load times. What a human sees in a browser is not always what a crawler or analytics tool sees when it follows the same link.

Side-by-side comparison

Here's how the three approaches compare across the checks that matter for campaign link quality:

The pattern is clear. URL builders stop at link generation. mlz preflight treats link generation as step one and then validates everything downstream of it. The complete picture of what campaign link validation means covers all of these checks and why each one matters.

Real example: catching a broken OG image before launch

Here's a scenario that plays out regularly. A marketing team builds a LinkedIn campaign link using the Google URL Builder, pastes it into their post, and publishes. The link is structurally valid — all UTM parameters are present and properly formatted. But the landing page's og:image tag was accidentally removed during a recent deploy.

The Campaign URL Builder never made a request to the page. It had no way to know. LinkedIn crawls the URL when someone posts it, finds no og:image, and renders the post with no preview image — a plain text URL in the feed. Click-through rate drops by roughly 60% compared to a post with a rich image preview. The team spends the budget, sees the underperformance, and doesn't know why until someone checks the page source manually.

With mlz preflight, that failure surfaces before the post is published:

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

checks:
  PASS  ssl              URL uses HTTPS
  PASS  resolution       Destination responded with 200
  PASS  redirects        No redirect chain detected
  PASS  response_time    Page loaded in 420ms
  FAIL  og_tags          Missing og:image — social previews will be blank
  PASS  twitter_card     Twitter Card tags configured
  PASS  viewport         Viewport meta tag present
  PASS  canonical        Canonical URL matches destination
  PASS  favicon          Favicon found
  PASS  utm_valid        All required UTM parameters present
  PASS  utm_preserved    UTM parameters preserved through redirects

summary:      10 passed, 0 warnings, 1 failed
verdict:      Do not publish. Fix og:image before launch.

One check failed: og:image is missing. The verdict is clear and actionable — fix the tag before publishing. The Campaign URL Builder would have produced the same tracked URL and told you nothing was wrong. This is the gap that mlz preflight closes.

For more on OG tag checking, see how to check if your landing page has OG tags.

FAQ

Does mlz preflight replace Google's Campaign URL Builder?

For generating UTM links, yes — mlz preflight builds the tracked URL as part of its output. The Campaign URL Builder is a web form that generates a string. mlz preflight generates the same string and then validates it. For teams that also need link storage, campaign organization, and team collaboration, MissingLinkz covers those too via the mlz campaigns and mlz links commands.

What does mlz preflight check that UTM.io doesn't?

UTM.io checks naming convention consistency when you build a link. It does not request the destination URL, check SSL, follow redirect chains, verify UTM parameter preservation, or inspect Open Graph or Twitter Card tags. mlz preflight does all of those.

Is mlz preflight useful if I'm not running paid campaigns?

Yes. Any link that will receive traffic benefits from a preflight check. Social posts, newsletter links, press release URLs, and partnership referrals all need the same validation as paid ads. The cost of a missed og:image is the same whether the traffic is paid or organic.

Can I run mlz preflight in a CI/CD pipeline?

Yes. mlz preflight outputs structured JSON and exits with a non-zero status code when checks fail. You can use it in GitHub Actions or GitLab CI to block deploys when campaign link validation fails. See automating campaign link validation in CI/CD for a complete workflow.

How long does a preflight check take?

Usually 1–3 seconds per URL. The check makes one request to the destination URL, follows any redirects, and inspects the response. For bulk validation across many URLs, the checks run sequentially; a 10-link campaign takes roughly 10–30 seconds.

Related reading