DEV Community: 任宏涛

Nine SEO checks to run before you publish a page

任宏涛 — Wed, 23 Sep 2026 03:35:11 +0000

The problem with SEO checklists

Most of them list things you can see. The real problems are the ones you can't.

A missing canonical, a duplicated h1, a meta description that gets truncated — none of these break anything. The page renders, the content is good, and you find out weeks later in a report nobody reads closely.

So this is a list of checks for invisible failures. The order is deliberate: structural checks first, because fixing structure usually changes the text, and re-running the content checks after a rewrite wastes the first pass.

1. Does the page have exactly one `h1`?

Not zero, not two.

Zero usually means the title was styled with a class instead of a heading element. Two usually means a template printed the site name as an h1 and the page title as another one.

Both are invisible in a browser, and both make the page's main subject ambiguous.

Read the heading outline rather than an issue count. If the h2 list reads like a table of contents for the page, the structure is fine.

2. Do heading levels descend without skipping?

An h2 followed by an h4 tells a reader a level is missing.

Sometimes a level genuinely is missing and the outline is still correct — but more often the h4 was chosen for its smaller font size.

Choose levels for meaning and style them in CSS. Nothing in HTML requires an h2 to be visually larger than an h3.

3. Is the title tag specific to this page?

Open ten tabs of your site and read the titles.

If several are identical, those pages compete for the same query and none of them wins clearly. A title should describe what this page covers, not the category it belongs to.

4. Will the description survive truncation?

The widely quoted 155-character limit is an average, not a rule. The real constraint is rendered pixel width, and mobile is meaningfully narrower than desktop.

Put the sentence that must survive in the first ~120 characters and treat the rest as elaboration.

Preview it rather than counting — measure in pixels, not characters.

5. Does the canonical point at itself?

A page's canonical should be its own URL, in the same form the page is served at.

Trailing slashes are the common case. If /tools redirects to /tools/, the canonical must say /tools/ — otherwise you're telling Google the real page is a URL that redirects.

Check index pages specifically. They're the ones most often generated with a canonical that omits the trailing slash.

6. Is the page in the sitemap, in the right URL form?

Same trailing-slash question. A sitemap entry that redirects is a wasted crawl.

If your sitemap is generated, generate it from the same value as the canonical. Two independent string constructions will eventually disagree — and nothing will tell you when they do.

// Wrong: two places that must agree, with nothing enforcing it
const canonical = `${SITE}/blog/${slug}`;
sitemap.push(`${SITE}/blog/${slug}/`);   // ← drifts

// Right: one value, used twice
const url = `${SITE}/blog/${slug}/`;

7. Are the internal links real and useful?

Every new page should link to at least two existing pages, and at least one existing page should link to it.

A page nothing links to is a page that's hard to find. Internal links are the only navigation signal you fully control.

Use descriptive anchor text. "Read the guide" tells a reader nothing about where it goes.

8. Do images have dimensions and alt text?

Set explicit width and height on every image.

Without them the browser can't reserve space, and the page shifts as images load — the single most common cause of a bad layout-shift score.

<img src="/chart.png" width="800" height="420" alt="Response time by region">

Alt text describes the image for someone who can't see it. If the image is purely decorative, alt="" is correct — and better than a description nobody needs.

9. Does the structured data describe this page accurately?

If you mark up an Article, the headline should match the visible title and the dates should be real.

If you mark up an FAQPage, those questions must be visible on the page. Markup describing content that isn't there is a violation, not an optimisation.

What is deliberately not on this list

Keyword density. There's no target to hit, and writing to one produces worse text. Run a density check only to see whether the page is actually about the topic you intended — if the top phrases surprise you, that's a content problem, not a density problem.

Word count. Length is a consequence of covering the subject, not a goal. A page that answers the question in 400 words is finished. Padding it to 1200 makes it worse.

Meta keywords. Ignored for over a decade.

The full version of this, with the reasoning behind each item, is on SerpPrism. The tools mentioned above — heading analyzer, SERP preview, robots.txt tester — all run client-side, nothing is uploaded.

Curious whether anyone has a check I've missed. The one that keeps biting me is #5, because the failure only shows up on index pages.

I checked the Open Graph tags on 62 homepages. Here's what's actually broken.

任宏涛 — Wed, 23 Sep 2026 03:35:02 +0000

Open Graph tags don't affect rankings. They decide something narrower and easier to forget: whether your link renders as a card with an image, or as a bare grey link that people scroll past.

I got curious about what's actually in the wild, so I fetched the homepages of 78 well-known domains and parsed every <meta> tag whose property or name started with og: or twitter:. 62 came back usable.

Here's what I found, including one failure mode I had never considered.

Method, and the two counting rules that changed the numbers

78 domains, 62 usable homepages. Two rules mattered:

An empty or missing content attribute counts as absent. og:title="" is a tag that exists and says nothing. If you count it as present, you inflate your numbers and — as it turns out — hide the most interesting bug in the dataset.

No JavaScript was executed. This is server-rendered HTML only. That's usually fine for social tags (they're server-rendered because crawlers don't run JS), but it means every percentage below is a floor, not a rate.

Finding 1: Open Graph is near-universal. Twitter cards are not.

56 of 62 homepages (90%) had at least one Open Graph tag. But that headline hides how patchy individual fields are:

tag	count	%
`og:title`	54/62	87%
`og:description`	53/62	85%
`og:url`	49/62	79%
`og:image`	48/62	77%
`og:type`	48/62	77%
`og:site_name`	40/62	65%
`og:locale`	22/62	35%

So about one homepage in four has no shareable image.

The Twitter side is where the real gap is. Of the 62:

34 (55%) declared twitter:card = summary_large_image
14 (23%) = summary
2 (3%) = app
12 (19%) declared no twitter:card at all

That last group is the one to care about. X falls back to Open Graph for title, description and image — but it still needs twitter:card to know which layout to build. Without it you get a plain link, no matter how good your Open Graph tags are.

Finding 2: two sites ship an `og:image` tag with nothing in it

I expected this to be common. It wasn't: only 2 of the 34 sites declaring summary_large_image had no usable image. But the two fail differently, and one of them is genuinely sneaky.

netflix.com declares twitter:card = summary_large_image and twitter:site, and nothing else. No og:image, no og:title, no og:url. The card type promises a large image that was never supplied.

forbes.com does emit the tag:

<meta property="og:image" name="image" data-next-head=""/>

There is no content attribute at all.

This is the failure mode worth internalising. A missing tag fails loudly — any validator catches it. A present-but-empty tag passes every "is it there?" check and renders nothing. If your audit tool asks "does og:image exist?", Forbes returns yes.

Its twitter:image has the same shape, and its og:image:type is:

<meta property="og:image:type" content="image/jpeg,image/gif,image/png" data-next-head=""/>

A comma-separated list. Not a single MIME type. Not a valid value for that field.

You can spot this in one line:

curl -s https://example.com | grep -o '<meta[^>]*og:image[^>]*>'

If the tag shows up with no content=, you've found it.

I should be candid that I had this exactly backwards: until the day I collected this data, all 25 pages on my own site declared summary_large_image with no og:image. The pattern that turns out to be rare in the wild was on every page of my site.

Finding 3: only 23% declare image dimensions

Of the 48 homepages with a usable og:image, just 11 (23%) also declared og:image:width and og:image:height.

This sounds harmless. It isn't, and the reason is subtle: without dimensions the platform has to download the image before it can lay out the card. If that fetch is slow, rate-limited, or blocked — a CDN that dislikes the crawler's user agent, a region where the image host is slow — the first share goes out with no image and the second one works.

An intermittent bug like that is far harder to diagnose than a missing tag, because by the time you look, it works.

The 11 that do declare dimensions: figma.com, x.com, docker.com, developer.mozilla.org, w3.org, moz.com, screamingfrog.co.uk, yoast.com, searchenginejournal.com, harvard.edu, heroku.com.

Four of those — Moz, Screaming Frog, Yoast, Search Engine Journal — are SEO vendors or publications. All four SEO sites in the sample declare dimensions, against 23% overall. They're also the same four that showed up as @graph users when I ran the equivalent survey on JSON-LD. Consistent signal: the sites whose business is this metadata treat it better than average by a wide margin.

Only 5 of 48 (10%) declared og:image:alt. Alt text on a social card isn't decorative — it's what a screen reader announces.

Finding 4: one in four `og:title` disagrees with `<title>`

14 of the 54 homepages with both showed different text in each (26%).

Most are trivial: github.com drops a trailing "· GitHub" from the Open Graph version. Some aren't. kubernetes.io ships:

<title>Kubernetes</title>
<meta property="og:title" content="Production-Grade Container Orchestration">

The search result says one thing; the shared link says another. Neither is wrong — but it means the title you optimised for search isn't the one people see when the page is shared, and those are written for different purposes. If you only check one, check the one that appears in search.

Finding 5: the things I expected and didn't find

Across 48 usable images:

1 relative path (kubernetes.io, /images/kubernetes-open-graph.png)
0 http:// images
0 sites declaring more than one og:image

Relative og:image URLs are the classic warning — scrapers have no base URL to resolve against, so the tag gets dropped. It happened once in 48. Insecure images, not at all.

This is the third survey in a row where a widely repeated warning turned out to be rare at this sample size. That's not an argument for ignoring the warnings. It's an argument for checking the base rate before you spend a day on the thing you're worried about.

What to check on your own tags

Is the image tag carrying anything? View source, look for content=. Present-but-empty is the check no validator does for you.
Do you declare width and height? Two lines, kills the "first share has no image" failure mode.
Do you declare twitter:card? One in five sites skip it.
Does og:title match your title? If not, pick which one you meant.

The full dataset — including the raw HTML for all 62 domains, so you can check any claim against the markup rather than my summary of it — is on SerpPrism. There's also a preview tool that renders what your tags will actually produce.

If you find a row that's wrong, the markup settles it — and I'd genuinely like to know.

Your JSON-LD is duplicated in three places. Here's the fix.

任宏涛 — Wed, 23 Sep 2026 03:34:12 +0000

The pattern almost everyone starts with

You add an Organization block to the footer. An Article block to the article template. A BreadcrumbList to the breadcrumb component. Three separate <script type="application/ld+json"> blocks, each describing one thing.

It works — Google reads all of them — and it's where most sites stop.

The cost isn't visible immediately. It shows up the first time you rename the company, change the logo URL, or move domains. Now you have three places containing the same facts, and nothing enforces that they agree. One gets updated, the others don't, and your structured data now contradicts itself in a way no error message will tell you about.

What `@id` actually does

Every node in JSON-LD can carry an @id — a stable identifier. A URL is conventional.

Once a node has an @id, any other node can refer to it instead of repeating its properties.

So instead of the Article containing its own copy of the publisher's name and logo:

{
  "@type": "Article",
  "publisher": {
    "@type": "Organization",
    "name": "Acme",
    "logo": { "@type": "ImageObject", "url": "https://acme.com/logo.png" }
  }
}

…it contains a reference:

{
  "@type": "Article",
  "publisher": { "@id": "https://acme.com/#organization" }
}

The full description lives once, in a node other nodes point at. Change the logo in that one place and every reference is correct.

The shape that works

One @graph array in the page head, containing in order:

Organization
WebSite
WebPage (for the current URL)
whatever page-specific nodes apply — Article, FAQPage, HowTo, Product

The Organization and WebSite nodes are identical on every page — that's the point. They're declared once per page but defined consistently, and page-specific nodes reference them by @id rather than restating them.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://acme.com/#organization",
      "name": "Acme",
      "url": "https://acme.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://acme.com/#website",
      "url": "https://acme.com/",
      "publisher": { "@id": "https://acme.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://acme.com/blog/post#webpage",
      "url": "https://acme.com/blog/post",
      "isPartOf": { "@id": "https://acme.com/#website" },
      "datePublished": "2026-03-14",
      "dateModified": "2026-08-02"
    },
    {
      "@type": "Article",
      "@id": "https://acme.com/blog/post#article",
      "headline": "…",
      "mainEntityOfPage": { "@id": "https://acme.com/blog/post#webpage" },
      "publisher": { "@id": "https://acme.com/#organization" }
    }
  ]
}

Four nodes, one block, every relationship explicit.

Three ways this goes wrong

1. Referencing an @id that doesn't exist on the page.

If the Article says its publisher is #organization but no node with that @id is present, the reference resolves to nothing. Google handles this by ignoring the property — so the symptom isn't an error, it's silently missing data. Always include the node you reference.

2. Reusing the same @id for different things.

Identifiers must be unique. Two nodes sharing an @id means you've declared two contradictory definitions of one entity, and the outcome depends on which one a consumer reads first.

3. Relative @id values.

Use absolute URLs. A relative reference like #organization is interpreted against the page URL, which means the same markup on two domains produces two different identifiers — and any cross-page relationship you were expressing breaks.

Dates deserve their own section

datePublished should never change after the page goes live.

dateModified should change when the content genuinely changes, and not otherwise.

Incrementing dateModified on every deploy is a common habit, usually adopted because someone believed freshness helps rankings. It doesn't — and the pattern is trivially detectable: a modified date that advances daily while the words stay identical tells any consumer the field is noise, which means it gets discounted on the pages where it was actually true.

If you use a build system, wire dateModified to a per-page content hash, not the build timestamp:

import crypto from "node:crypto";

const hash = crypto
  .createHash("sha256")
  .update(pageBody)
  .digest("hex")
  .slice(0, 12);

// store hash → date in a committed JSON file
// update the date only when the hash changes

The field then moves only when the content does.

Checking your markup

Validate with Google's Rich Results Test (for eligibility) and the Schema Markup Validator (for syntax).

Neither will tell you that your @id references are dangling — a dangling reference is not a syntax error.

The check that catches it takes a minute and is manual:

Extract every @id defined in the page
Extract every value used in a reference
Confirm every reference appears in the defined list

On a page with six nodes this is faster by eye than to automate.

I built a small generator for this shape that validates required properties as you type — SerpPrism's JSON-LD generator. It's client-side, nothing is uploaded. There's also a longer version of this post with a few more edge cases on the site itself.

Happy to hear how other people handle the dateModified problem — it's the one I've seen go wrong most often in production.

Building a 6-book series: the Tier Zero roadmap from Systemfall to Tier IX

任宏涛 — Fri, 04 Sep 2026 01:47:19 +0000

Tier Zero is 6 books. One falling system. One protagonist who refuses to stay assigned.

Start at Systemfall (Book 1) to Tier IX (Book 6).

If you like Cradle, Nightfall, or anything with a hard magic system and a rebel streak — this is your next binge.

The premise: in a world where human potential is quantified into Tiers by a controlling system, one person drops to Tier Zero and becomes untrackable. What follows is a progression-fantasy climb through a cyberpunk dystopia where the rules of power are enforced by something that can no longer see him.

Book 1 Systemfall is on Kindle now. Happy to answer worldbuilding questions in the comments.

ProgressionFantasy #BookSeries #IndieAuthor #SciFi

I wrote a 6-book cyberpunk progression fantasy. Here's the premise.

任宏涛 — Thu, 03 Sep 2026 07:11:50 +0000

Tier Zero follows a world where human potential is quantified into Tiers by a controlling system — until one person drops to Tier Zero and becomes untrackable.

The series spans six books (Systemfall → Tier IX), blending progression-fantasy power curves with cyberpunk dystopia and a hard, consistent magic system.

If that sounds like your kind of read, Book 1 "Systemfall" is on Kindle now. Happy to answer worldbuilding questions in the comments.

SelfPublishing #SciFi #Cyberpunk #ProgressionFantasy