Fixing your site's metadata: a practical checklist

You've done it. You're finally done building the website or application you've been working on for quite a while. Proud and elated, you go to share this on your socials or to your buddies - uh oh, what's this now? The preview in WhatsApp shows no headline, your avatar is cropped and dimensions seem wrong. I've been there too. The site looked fine in the browser. The problem was everything outside the browser: link previews, search snippets, and tab icons all use a separate metadata layer most of us skip until something breaks. So, how do you fix this? Use this as a pre-launch checklist - or run it on a site that's already live but sharing badly. What I ran into on my own portfolio When I ran this audit on shwethaadiraj.com, the site rendered fine - but sharing it told a different story. I had pointed both the favicon and Open Graph image at my profile avatar. At tab size the illustration was unreadable; in link previews it got cropped awkwardly. An OG validator then flagged two things I hadn't considered: the image was 512×512 (most platforms expect 1200×630), and there was no headline or CTA on the image itself - so Slack and LinkedIn showed a plain square with none of the context from my meta title. I replaced the favicon with a simplified monogram, regenerated the OG image at the correct aspect ratio with my name, tagline, and site URL on it, and re-ran the debuggers. Even then, previews didn't update until I hit Scrape Again - platforms cache OG data aggressively, so fixes on your end won't show up until you bust that cache. None of this required rethinking the app. It was a metadata pass - the kind of work that's easy to defer and annoying to discover at the share button. Before we get into the specifics, here's a primer on what metadata can actually impact: What is metadata for? Metadata, simply put, is data about data. Search engines, crawlers and social sites all parse different metadata from your app. - Search & Discovery: The title and description in your app's tags tell search engines, crawlers, and AI chatbots how relevant your content is to a user's query. - Social Platforms: Open Graph (OG) and Twitter/X cards give you more control over how your app is presented when shared on social platforms. - Browser: Adding favicons and apple touch icons helps consolidate your brand identity across browser tabs, notifications and bookmarks. The metadata audit checklist A page can render properly and function well but it can still fail when it comes to browser, socials or search engine checks. Run this audit on every public-facing page on your app. 1. Favicon and touch icons - Does the browser tab show a clear icon at 16×16 and 32×32? - Is there a dedicated Apple touch icon (typically 180×180) for “Add to Home Screen”? - Is the favicon a simplified mark, not a full photo or illustration? - Are favicon URLs absolute (or resolvable via a consistent base URL)? Why it matters: Large images or detailed illustrations lose detail at tab size. Users with many tabs rely on favicons to find your site. A blurry or generic icon makes the site look unfinished even when the page itself is polished. How to verify - Open the site in a browser and inspect the tab icon. - Visit the favicon URL directly (e.g. /icon or/favicon.ico ). - On mobile, add the site to the home screen and check the icon. - Use a favicon checker or DevTools → Application → Manifest / Icons if you ship a PWA manifest. 2. Page title and description - Does every route have a unique ? - What is the length of the titles? Are they concise and readable? - Does every page have a description summarizing content of that specific page? Why it matters: Title and description are what show up in Google results and often in link previews when OG tags are missing. Duplicate or empty metadata makes pages compete with each other and look spammy in search. How to verify - View page source and search for andname="description" . - Paste the URL into a search preview tool and confirm the title/description match what you expect. 3. Canonical URL - Does every page declare one canonical URL via ? - For your app or any routes in it, is it app.com/blog/ orapp.com/blog ? Why it matters: Search engines treat duplicate URLs (http/https, www/bare, trailing slash variants) as separate pages. Canonical URL tells them which version to index and pass ranking signals to. How to verify - View source on each page type and find link rel="canonical" . - Confirm the href matches the URL you'd share publicly. - Try alternate forms (with/without www, with trailing slash) and check redirects or canonical tags. 4. Open Graph and social link previews - Does your page have og:title ,og:description , andog:url , and do they match the page content? - Are the image dimensions in og:image 1200×630 (1.91:1)? - Does the image include readable headline and/or CTA text - many validators flag “no conversion text” because platforms often show the image without your meta title overlay. - Are twitter:title ,twitter:description , andtwitter:image defined and aligned with Open Graph tags? - Does twitter:card match your image:summary_large_image for wide OG art,summary only for small square cards? Why it matters: These tags control how your link appears on Slack, LinkedIn, iMessage, and X. Wrong aspect ratio gets cropped; missing image means no preview. X can fall back to OG tags, but explicit Twitter tags and the right card type avoid inconsistent layouts. How to verify - opengraph.xyz - paste URL, inspect warnings. - Facebook Sharing Debugger - use “Scrape Again” after fixes. - LinkedIn Post Inspector - Twitter Card Validator - Open your og:image URL directly in the browser - confirm it loads and reads at thumbnail size. - Compare previews across at least two platforms for the same URL. 5. Robots and indexing - Does your robots.txt allow crawling of public pages and block only private or paywalled content? - Is the sitemap URL declared in robots.txt ? Why it matters: Accidentally blocking / or omitting the sitemap slows discovery. Blocking too little exposes internal paths to crawlers. How to verify - Visit /robots.txt on production. - View source for on key pages. - Google Search Console → Pages / Sitemaps (if you use it). 6. Sitemap - Does /sitemap.xml exist and return valid XML? - Do new routes get added when you ship pages? - Is the URL in your sitemap matching canonical URL structure? Why it matters: Sitemaps help search engines find pages that aren't heavily linked. How to verify - Open /sitemap.xml in the browser. - Count URLs vs what you expect to be public. - Resubmit in Search Console after major additions. Going further: agentic browsing Once the basics above are solid, there's a second audience worth optimizing for: AI agents browsing on behalf of users. That means accessibility tree completeness, llms.txt, layout stability, and eventually APIs like WebMCP. I wrote a separate post on this - Your Website's New Audience: AI Agents - but the order matters: get favicons, Open Graph, and canonical URLs right first, then layer agent-ready improvements on top. Closing thoughts When building any new application, people focus on the app itself - metadata gets deferred until you share a link and it looks unpolished. You don't need every advanced technique on day one - get titles and descriptions, canonical URLs, favicons, and Open Graph images right first; robots.txt and sitemap next. That covers the failures people actually notice. I've been experimenting with a Cursor agent skill that runs this checklist against a real codebase - try it on your project and let me know how it works. Top comments (0)