On-Page SEO and Link Preview Checklist for Small Business Sites

Two places your website gets judged before anyone visits

A coaching institute shares its new batch page in a parents' WhatsApp group. The preview shows a grey box, the domain name and nothing else. Nobody taps it. The same page also shows up in Google with a title cut off halfway and a description pulled from the cookie banner.

Both problems come from the same few lines of HTML in the page's <head>. They are cheap to fix, and most small business sites get several of them wrong.

This checklist follows the order we use in the free Mecverse SEO checker, which fetches a page the way a crawler does and runs 30+ checks across indexability, on-page tags, content, links and images, social sharing and technical health. You can follow it by hand, or run the tool and work through what it flags.

Step 1: Make sure Google can index the page

Nothing else on this list matters if the page cannot be crawled and indexed. Check these first.

1. HTTP status is 200. A 4xx or 5xx response gets the URL dropped. Redirects are fine, but chains of two or more hops slow users down and waste crawl effort. Link straight to the final URL.
2. No accidental noindex. Look for <meta name="robots" content="noindex"> and for an X-Robots-Tag response header. Both are common leftovers from a staging site that went live.
3. robots.txt does not block the page. Your /robots.txt should return 200 (or 404 if you have none). A server error on robots.txt is worse than having no file, because Google treats it as a temporary instruction not to crawl the site.
4. A canonical tag points at the preferred URL. A self-referencing canonical consolidates duplicates created by tracking parameters, http vs https and trailing slashes.
5. An XML sitemap exists at /sitemap.xml or is declared in robots.txt, and is submitted in Google Search Console.

A minimal robots.txt for a small business site looks like this:

User-agent: *
Allow: /

Sitemap: https://www.example.com/sitemap.xml

And the canonical tag sits in the page head:

<link rel="canonical" href="https://www.example.com/services/">

Google's own documentation on robots.txt and canonical URLs covers the edge cases.

Step 2: Titles, descriptions and headings

These tags decide how your page looks in search results and how clearly search engines understand its topic.

Title length is really about pixel width, so treat 60 characters as a guide rather than a hard limit. The point is that the important words come first, before any truncation.

For a CA firm's GST services page, the head might look like this:

<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GST Registration and Filing in Ahmedabad | Shah & Co</title>
  <meta name="description" content="GST registration, monthly returns and annual filing for small businesses in Ahmedabad. Fixed fees, WhatsApp updates, 15 years in practice.">
  <link rel="canonical" href="https://www.example.com/gst-services/">
</head>

Step 3: Open Graph tags for WhatsApp, LinkedIn and Facebook previews

When someone pastes your link into WhatsApp, LinkedIn, Facebook or Slack, the app fetches the page and reads a handful of Open Graph tags. Those tags decide the headline, the line of text and the picture in the preview card.

<meta property="og:title" content="New JEE Foundation Batch, Starts 1 November">
<meta property="og:description" content="Weekend batch for Class 9 and 10 students. Small groups, weekly tests, free demo class.">
<meta property="og:image" content="https://www.example.com/images/share-jee-batch.jpg">
<meta property="og:url" content="https://www.example.com/jee-foundation/">
<meta name="twitter:card" content="summary_large_image">

Why the image does not show

A missing preview image almost always comes down to one of these:

• There is no og:image tag at all.
• The URL is relative (/images/share.jpg). Facebook and LinkedIn need the full https:// address.
• The image URL returns an error, or points at a page instead of an image file.
• The image is blocked for bots by a firewall or hotlink protection.
• The file is very large, and some apps skip heavy images.

Size matters too. A 1200x630 image (a 1.91:1 ratio) displays well on Facebook, LinkedIn, X and Slack. Smaller images get shown as a small thumbnail, and other ratios get cropped differently by each app.

If you only care about previews, the link preview checker loads your share image, checks its size and shows approximate previews for Google, Facebook, LinkedIn, X, WhatsApp and Slack.

Step 4: Content, structured data, images and links

Enough text in the HTML

Pages with very little text rarely rank. Around 300 words that actually answer the visitor's question is a reasonable floor for a service page. One catch: if your text is rendered by JavaScript after the page loads, it may not be in the raw HTML that crawlers fetch first. Server rendering or static generation fixes that for search engines and AI crawlers alike.

Structured data

JSON-LD markup from schema.org (Organization, LocalBusiness, Product, Article, FAQPage) helps search engines understand the page and can make it eligible for rich results. Invalid JSON is worse than none, so validate it with Google's Rich Results Test.

Images

• Give every meaningful image alt text that describes it. Use alt="" for decorative images.
• Set width and height on every image so the layout does not jump while it loads. That jump is measured as Cumulative Layout Shift, one of Google's Core Web Vitals.

Links

• Link to related pages on your own site, so crawlers find them. A clinic's home page should link to each treatment page, not just to "Services".
• Use descriptive anchor text: "see root canal pricing" rather than "click here" or "read more".

Step 5: HTTPS, security headers and speed

These checks are mostly a hosting question, which is why they tend to slip on sites nobody maintains.

• HTTPS everywhere, with http redirecting to https. Free certificates from Let's Encrypt are standard now.
• HSTS header (Strict-Transport-Security: max-age=31536000) so browsers never fall back to http.
• No mixed content. Every image, script and stylesheet loads over https.
• Fast server response. Our checker passes a time to first byte under 600 ms and fails anything over 1.5 seconds. Slow servers drag down Largest Contentful Paint. Caching, a CDN or better hosting are the usual fixes.
• Compression on. gzip or Brotli on the server or CDN shrinks HTML considerably.
• Lean HTML. Under about 100 KB is comfortable. Large inline data blobs are the usual cause of bloat.
• A favicon, since Google shows it next to your result on mobile.

For Core Web Vitals, including field data from real Chrome users where Google has enough of it, use PageSpeed Insights. A single-page checker measures the server, not the visitor's phone.

The one-page checklist, in priority order

Work top to bottom. Fails before warnings, indexability before everything.

1. Page returns 200, with at most one redirect.
2. No noindex in meta robots or the X-Robots-Tag header.
3. robots.txt returns 200 or 404 and does not block the page.
4. Self-referencing canonical tag.
5. XML sitemap published, listed in robots.txt and submitted in Search Console.
6. Unique title, 30 to 60 characters.
7. Meta description, 70 to 160 characters.
8. One H1, headings in order.
9. lang, viewport and charset set.
10. og:title, og:description, og:url and an absolute 1200x630 og:image under about 1 MB.
11. twitter:card set to summary_large_image.
12. 300+ words of real text in the server-rendered HTML.
13. Valid JSON-LD for the business and page type.
14. Alt text and width/height on images.
15. Internal links with descriptive anchor text.
16. HTTPS, HSTS, no mixed content.
17. Server responds in under 600 ms, with compression on.
18. Favicon declared.

To check all of this in one go, paste your URL into the Mecverse SEO checker. It is free with no signup and does not store your URL. Each issue comes with the fix, a copyable prompt for an AI coding assistant, and PDF, CSV or JSON export if you need to hand the report to whoever manages your site. If that person is nobody, our website care plans cover hosting, updates and small fixes like these.