5 Things to Check Before You Hit Publish on a New Landing Page

A landing page can look finished and still fail the moment someone tries to share it. The bugs that show up here don't break the page itself — they break what happens when the link leaves your browser, which is exactly the moment you have the least control over it and the most riding on it. Run through these five checks before you publish, not after a prospect tells you the link looked broken.

1. Title tag and meta description are actually set for this page, not inherited from a CMS default
2. og:image resolves to a real, page-specific image at a reasonable file size
3. The canonical tag points to the exact URL you intend people to share
4. Pasting the URL into Slack or a text message produces a preview that actually looks good
5. The page renders correctly on mobile and loads fast enough for a crawler to see it

Title and description: check they're not the CMS default

This is the single most common miss on a new page, because most CMS platforms are happy to publish a page with an empty or auto-generated title and description rather than blocking you. You end up with a title that's literally the page slug, or a description pulled from the first sentence of body copy that was never meant to be read out of context. Open the published page in an incognito tab and view source — don't trust the CMS editor's preview, since some editors show the field as filled even when what actually renders is a fallback.

og:image: confirm it's a real image, and the right one

It's easy to forget that a new landing page needs its own og:image rather than inheriting the site-wide default logo. A generic logo image isn't broken, exactly, but it's a missed opportunity on a page you specifically built to convert — a page-specific image with real context tends to perform better when shared. Separately, check that the image URL actually resolves: a broken image path is a silent failure that looks fine in the code and produces nothing in the preview.

Canonical tag: make sure it points where you think it does

Canonical tags get set wrong more often than they get left out entirely, usually because the page exists at more than one path — a staging URL that got copied into production, a tracking-parameter version shared in an ad campaign, or a duplicate created during an A/B test. If the canonical points to the wrong version, you can end up diluting signal across URLs that should be treated as one page, or worse, pointing search engines at a URL that no longer exists.

Paste the link and actually look at the preview

Checking that the tags exist in the source isn't the same as checking that they produce a good result. Paste the real, live URL into a Slack message or a text thread and look at what comes back before you send it anywhere that matters. This catches things that pass a tag-by-tag audit but still look wrong in practice — an image that's technically present but cropped badly at social aspect ratios, a description that's technically set but reads as truncated or awkward once it's sitting next to a headline and thumbnail.

Mobile rendering and load time

This one gets missed because it doesn't feel like an SEO or social-sharing issue on the surface — it feels like a performance issue. But social crawlers fetch your page on a timeout, same as any other automated request, and a slow page can cause the crawler to give up before it ever reads your meta tags, producing exactly the same missing-preview symptom as a page with no tags at all. Check the page on an actual mobile connection, not just a resized browser window, since local dev environments and fast office wifi both hide load-time problems that show up immediately in the real world.

All five of these show up in seconds if you paste the URL into a free scanner before you publish — useopengraph's scanner at useopengraph.com checks the tags, fetches the image, and shows you the rendered preview with no account required.