DEV Community: 任宏涛

How AI Search Engines Choose What to Cite

任宏涛 — Tue, 27 Oct 2026 00:00:00 +0000

The short answer

An AI search engine cites a page when three things are true at once: the page can be found and read by the system doing the answering, the page contains a fact stated plainly enough to be quoted, and something independent suggests the page is worth trusting. Miss any one of the three and the page is invisible to the answer, however good its content is.

That is the whole mechanism in one sentence, and it is worth holding on to, because most advice about "optimising for AI search" is really advice about one of these three conditions dressed up as something new. There is no separate secret ranking for AI answers. There is a retrieval step, a reading step, and a trust step, and each of them is mundane.

One more thing to say up front: no major AI company has published the exact formula its system uses to choose citations. Anyone who quotes precise weights, or a list of confirmed ranking factors for AI answers, is guessing. What follows is the behaviour that is observable from the outside — what the systems demonstrably do, and what site owners can verify for themselves.

First, the page has to be found and read

An AI answer is built from pages the system retrieved. Retrieval needs the page to be crawlable: a live URL, a 200 status, no robots rule blocking the AI crawler, and content present in the served HTML rather than injected only by JavaScript after load. A page that renders beautifully in a browser but ships an empty shell to a crawler has given the retrieval step nothing to work with.

This is the same crawlability that traditional search needs, and the checks are the same. Fetch the URL with curl and read what comes back. If the body is an empty container and a bundle of script tags, a retrieval system may never see the words you wrote. If your robots.txt blocks the AI crawlers by name, you have told them not to read the page at all — and several sites do this deliberately, because being cited is a choice, not an obligation.

The llms.txt file sits in this same step. It is a plain-text index, published at the root of a site, that lists the pages the site considers important, each with a one-line description. It is a proposed convention, not a standard, and no major AI company has formally committed to reading it. Treat it as cheap insurance: it costs minutes to publish, and any system that does look gets a curated map instead of having to guess which pages matter. Our own survey of 78 well-known sites found 22 serving one, which tells you adoption is real but far from universal — see the llms.txt survey for the numbers.

Second, the answer has to be quotable

Retrieval finds candidate pages; the system then has to extract an answer from them. The pages that get cited are usually the ones where the fact is stated in a form that can be lifted out intact: a short paragraph that answers one question, a definition in a single sentence, a table with labelled rows, a list of steps in order.

This is why the structure of a page matters more for AI citation than its length. A 3,000-word essay that never states its conclusion plainly is harder to quote than a 600-word page that opens with the answer and then explains it. The first paragraph of this guide is written that way on purpose: it is the answer, stated before the explanation, in language that survives being lifted out of context.

Practical consequences follow. Put the conclusion first, before the background. State numbers and dates as plain text, not only inside images or charts. Use headings that describe what the section answers, so a system scanning the page can tell which part is relevant. And avoid burying the key fact in the middle of a long paragraph where it cannot be extracted without the sentences around it. None of this is new writing advice — it is the same clarity that helps human readers — but AI retrieval rewards it more directly, because a machine cannot skim the way a person can.

Third, someone else has to vouch for the page

The hardest condition to fake, and the one most often skipped, is independent corroboration. A claim that appears on one site and nowhere else is a claim, not a fact. Systems that answer questions lean on pages that are linked to, listed in directories, mentioned in roundups, or cited by other pages on the same topic.

That is why the familiar signals still matter: links from real pages, listings in relevant directories, mentions in articles that are themselves trusted. They are not a separate "AI SEO" tactic. They are the same authority signals search engines have used for decades, doing the same job: telling the system that other people found this page worth pointing at.

It also explains why a brand-new page from an unknown site is rarely cited on its first day, even when its content is correct. The page has no history of being pointed at, so the system has no independent reason to prefer it over ten other pages saying the same thing. Time, links, and mentions are the slow part of this, and there is no shortcut that survives contact with a system designed to distrust shortcuts.

What this looks like on SerpPrism

This site is built around the three conditions above, and it is a useful worked example because every part of it is verifiable. Each tool page states plainly, in its first paragraph, that the tool is free, needs no sign-up, and runs entirely in the browser — three facts a system answering "is there a free tool that does X" needs in quotable form. The site publishes an llms.txt file at its root listing the tools and guides with one-line descriptions, so any crawler that reads the convention finds a curated map. And the guides library, including our AI crawler survey, publishes dated measurements with the method and the raw counts, so a claim on this site can be checked rather than taken on trust.

Note what this example does not claim. We do not claim any AI system has cited this site, because we have not verified that it has. We do not quote a citation rate, a share of AI answers, or a survey of what AI systems prefer, because we have not measured any of those. The example is about the structure being in place, not about a result we cannot evidence.

That distinction is the point of this guide. The work is to make a page findable, quotable, and corroborated. Whether a particular system cites it on a particular day is its decision, and any report that tells you otherwise is selling certainty it does not have.

What does not help

Stuffing pages with the exact phrasing of popular questions does not help, because retrieval is not keyword matching and the system reads the page, not the query log. Adding a block of hidden text, white-on-white keywords, or an invisible FAQ does not help either, for the same reason it never helped in traditional search: the content is judged on what is visible and coherent, and hidden text is a spam signal wherever it is found.

Publishing an llms.txt file and changing nothing else does not help much either. The file is a map, not a destination. If the pages it points at are thin, unquotable, or uncorroborated, the map only helps a system find them faster and dismiss them faster.

Finally, beware any tool or service that promises placement in AI answers. Citation is not an inventory you can buy, and the systems that answer questions have no advertising slot for it. A service that charges for "AI visibility" is charging for work you could do yourself — writing clearly, structuring pages so answers can be extracted, and earning mentions — with a guarantee attached that nobody can honour.

What to do on your own site

Check crawlability first. Fetch your key pages and confirm they return 200 with the content in the HTML. Check whether your robots.txt blocks AI crawlers, and decide deliberately: blocking is a valid choice, but it should be a choice, not an accident.

Rewrite the opening of each important page so it answers its own question. One paragraph, plainly stated, before the background. If you cannot write that paragraph, the page does not yet know what it is about.

Publish an llms.txt file. List the pages that represent what the site does, each with one line saying what it is for. Fifteen useful entries beat two hundred exhaustive ones. The llms.txt generator on this site writes the format for you.

Earn the corroboration. Get the page listed where people in your field actually look, and linked from pages that already get read. There is no faster honest version of this step.

Re-check after every redesign. A new template that moves content behind JavaScript, or a robots.txt edit that blocks a crawler group, can silently undo all four steps above. The failure is invisible in a browser, which is why it has to be checked rather than assumed.

Limitations

Everything here is inferred from observable behaviour, not from a published specification, because no such specification exists. AI systems change how they retrieve and cite without announcement, so a tactic that works this year may not work next year — the three conditions are structural, which is why they are the safest thing to build on, but they are not a promise.

There is also a measurement gap worth naming. We can verify that our own pages are crawlable, quotable, and listed, and we can verify that other sites publish llms.txt files. We cannot verify, from the outside, which pages a given AI system retrieved for a given question, because that retrieval is not observable. Any guide that reports such numbers without explaining how they were measured is reporting something it cannot know.

How Long Should a URL Slug Be?

任宏涛 — Tue, 27 Oct 2026 00:00:00 +0000

The short answer

Keep the slug — the part of the URL after the domain — short, lowercase, hyphenated, and carrying the words someone would use to describe the page. Three to five words is the working range for most pages. Anything longer is usually a sentence that escaped into the address bar, and anything shorter usually says nothing at all.

There is no official limit, and no ranking bonus for hitting a particular character count. The reasons to keep slugs short are practical: people can read them, remember them, paste them without breaking them, and tell what the page is about from the URL alone. A slug is a label, and labels work best when they are short.

What a slug is, precisely

For a URL like https://example.com/guides/how-long-should-a-url-slug-be, the slug is how-long-should-a-url-slug-be — everything after the last slash that identifies this one page. It is distinct from the domain, which identifies the site, and from any folders before it, which identify the section.

Search engines display the slug in results, browsers show it in the address bar, and people copy it into emails, documents, and chat messages. It is one of the few parts of a page that is seen by readers, crawlers, and linkers alike, which is why a small amount of care here pays off in three places at once.

The working rule

Three to five words, and never more than you need. A guide about meta descriptions can live at /meta-description-length. A guide about robots.txt mistakes can live at /robots-txt-mistakes. Both slugs say exactly what the page covers, and neither wastes words. If your slug needs a sixth word to be accurate, take the sixth word — the rule is a guide, not a limit — but ask first whether one of the first five is doing no work.

Lowercase only. URLs are case-sensitive after the domain, so /Guide and /guide are two different addresses. Mixed case creates duplicates that are invisible in a browser and confusing to everyone who links to the page. Pick lowercase once and never vary it.

Hyphens between words, never underscores or spaces. Search engines treat a hyphen as a word separator and an underscore as a joiner, so url-slug reads as two words and url_slug reads as one. Spaces are worse: they get encoded into unreadable percent sequences. Hyphens are the only separator that is readable by people and machines alike.

Words a person would use. The slug should contain the topic words of the page — the words someone would type to find it, and the words a reader would expect to see. This is not keyword stuffing; it is labelling. A slug of /page-47 tells nobody anything, while /url-slug-length tells everybody what the page is.

What to leave out

Dates. A slug containing /2024/ or october-update dates the page the moment it is published, and every later update makes the URL look stale. Dates belong in the page metadata, where they can be updated, not in the address, where they cannot be changed without breaking links.

Meaningless IDs. Numbers from a database, session tokens, and tracking parameters are not part of the page's identity. They make URLs unshareable — nobody pastes a link full of digits with confidence — and they create duplicate addresses for the same content, which is the canonical problem described in our canonical survey.

Stopwords you do not need. Words like "the", "and", "of", and "a" add length without adding meaning, and most slugs read better without them. But do not strip so aggressively that the slug stops making sense: /how-long-url-slug-be is shorter than /how-long-should-a-url-slug-be and harder to read. Remove the words that carry no information, keep the ones that hold the phrase together.

Repeated words and keyword lists. A slug of /seo-url-slug-seo-length-seo-guide is not more descriptive than /url-slug-length, it is just longer. Repeating a word does not make the page more relevant to it; it makes the URL look generated, and generated-looking URLs get fewer clicks and fewer links.

Changing a slug: the 301 rule

A slug is part of a page's address, and changing it breaks every link pointing at the old one. So the rule is simple: never change a slug without a 301 redirect from the old URL to the new one. A 301 tells search engines and browsers that the page has permanently moved, and passes the old URL's accumulated links and history to the new one.

That means a slug change is a small migration, not a typo fix. Before you change one, check what links to the old URL — internal links, external links, bookmarks, social posts, and any printed material. Update the internal links to point at the new URL directly, so they do not rely on the redirect, and leave the 301 in place indefinitely: removing it later breaks the external links you cannot update.

The other consequence is that a bad slug on a page nobody links to yet is cheap to fix, and the same bad slug on a page with years of links is expensive. This is the real argument for getting slugs right at publication time. The cost of a good slug is thirty seconds of thought before publishing; the cost of fixing a bad one later is a redirect, a link audit, and months of waiting for search engines to consolidate the two addresses.

Common mistakes

Letting the title become the slug. Most content systems generate the slug from the title automatically, and a long title produces a long slug. A title of "How Long Should a URL Slug Be, and Does It Even Matter for Rankings in 2026?" becomes a slug nobody can paste. Edit the generated slug down to the words that matter before publishing.

Using a different slug for the same page in different places. A page linked as /guide from the navigation and /Guide from an email is two addresses for one page. Pick one canonical form — lowercase, hyphenated, no trailing variation — and use it everywhere, including in your sitemap and your canonical tag.

Putting the whole category path in the slug. Folders are fine for organisation, but a URL like /blog/seo/technical/on-page/urls/how-long-should-a-url-slug-be buries the page under four levels of hierarchy. Two levels are usually enough; deeper than that, the folders are doing the labelling that the slug should be doing.

Changing slugs during a redesign. A redesign is the moment slugs get "tidied up" in bulk, which is also the moment hundreds of redirects get created at once. Redesign the design; leave the addresses alone unless a slug is actively wrong, and if you must change them, change them one at a time with a redirect each.

What to do

For a new page, write the slug after the draft is finished, when you know what the page actually covers. Three to five words, lowercase, hyphens, topic words only — then read the full URL out loud. If you can say it to someone and they can type it from memory, it is right.

For an existing page, audit the slugs that matter: the homepage's children, the pages with the most links, and the pages that appear in search results. Fix the ones that are unreadable, dated, or full of IDs — with a 301 each — and leave the rest alone. A slug that is merely inelegant is not worth a migration; a slug that misleads readers or breaks when pasted is.

And add the slug to your pre-publish check. The pre-publish checklist covers the canonical, the title, and the description; the slug belongs on the same list, because it is set at the same moment and is just as hard to change afterwards.

Limitations

Slug length is not a ranking factor, and this guide does not claim otherwise. A long slug will not push a page down, and a short one will not lift it up. What a short slug does is make the page easier to read, share, and link to — and links and clicks are the things that do move rankings, one step removed.

The three-to-five-word range is a working habit drawn from practice, not a measured threshold. Pages with longer slugs rank perfectly well, and pages with one-word slugs can be cryptic. Treat the range as a default to deviate from deliberately, not a rule to enforce blindly.

How Many Internal Links Should a Page Have?

任宏涛 — Tue, 27 Oct 2026 00:00:00 +0000

The short answer

There is no correct number of internal links per page, and anyone selling you one — five, ten, a hundred — is selling a rule that was never measured. Link where a reader would genuinely want to go next, make sure every important page is reachable from the homepage within three clicks, and make sure no page is reachable from nowhere at all. Those three tests cover everything a number would pretend to cover.

Internal links do three jobs at once, and the confusion starts because people count links as if only one job mattered. They help readers navigate, they tell crawlers which pages exist and how they relate, and they distribute the authority a site has earned across its pages. A count optimises none of the three. A reader who finds the next step, a crawler that can reach every page, and a new page that inherits links from established ones — that is what good internal linking looks like, and it has no fixed total.

Why no number exists

Google has never published a limit, and the old guideline of "no more than 100 links per page" was withdrawn years ago. It was a crawling concern from an era when pages were simpler and crawlers weaker, not a quality judgement, and it has not been relevant for a long time.

The deeper reason is that pages differ. A short answer page may need two links: one to the detailed guide, one back to the section it belongs to. A long reference page may need thirty, because it touches thirty topics a reader might want to explore. A navigation page may need hundreds, because its entire job is to list destinations. Judging all three by one number would mean the short page is over-linked, the reference page is under-linked, and the navigation page is broken — and all three judgements would be wrong.

What matters instead is whether each link earns its place. A link earns its place when a reader following it learns something the current page does not say, or reaches a tool that does something the current page only describes. A link that points at a page the reader has already read, or at a page with nothing new to add, is clutter — and clutter is the only real excess in internal linking.

The three-click rule

If one number is worth keeping, it is not a count of links but a count of clicks: any important page should be reachable from the homepage within three clicks. Homepage to section page is one, section page to article is two, article to related detail is three. Beyond three, a page is deep enough that both readers and crawlers reach it rarely, and rarely-visited pages are rarely indexed, rarely linked, and rarely read.

Three is a working rule, not a law. A large site with thousands of pages will have some pages four clicks deep, and that is fine if those pages are genuinely minor. The rule is a diagnostic: if a page you care about is five clicks from the homepage, that is a structural problem, and the fix is not to add links to that page alone but to reconsider the section it lives in. Deep pages are usually a symptom of a section that grew without a plan.

Note the direction of the fix. When a page is too deep, people add a link from the homepage to it, which technically satisfies the rule and helps nobody: a homepage with a hundred direct links is not navigation, it is a sitemap pasted into the header. The right fix is to give the page a proper parent — a section page that lists it alongside its siblings — so the path is short and the journey makes sense.

Orphan pages are the real problem

An orphan page is one that nothing links to: no navigation entry, no link from another article, no mention anywhere on the site. The only way a crawler can find it is through the sitemap, and the only way a reader can find it is by knowing the URL. Our guide to why pages are not indexed lists this as one of the most common causes of a technically perfect page never being indexed, and it is the internal-linking failure that actually costs traffic.

Orphans happen quietly. A page is published, the author means to link to it from the overview article, the overview is never updated, and the page sits alone. A redesign drops a section page, and the ten articles under it lose their only parent. A draft is published from a preview link and nobody adds it to the index. None of these are dramatic, which is why they accumulate.

Finding them is mechanical. List every URL in your sitemap, list every URL that receives at least one internal link, and compare the two sets. Any URL in the first list but not the second is an orphan. Fix it by linking to it from the page a reader would most naturally arrive from — usually the overview or the article that mentions its topic — and add that link to your publishing checklist so the next page does not repeat it.

Anchor text: say where the link goes

The clickable words of a link should describe the destination. "Read our guide to meta description length" tells a reader what they will get; "click here" tells them nothing, and "read more" tells them slightly less than nothing. This matters for readers first — people scan links before clicking them — and for crawlers second, because anchor text is one of the signals used to understand what the destination page is about.

Two habits to avoid. The first is using the same anchor text for different destinations, which tells both readers and crawlers that two different pages are the same thing. The second is forcing the exact same keyword phrase into every link to a page, which reads as manipulation and makes the text worse. Describe the destination in the words that fit the sentence you are writing, and vary them naturally.

One more point worth stating: link from the body of the page, not only from navigation and footers. A link inside a paragraph, at the point where the reader is thinking about the topic, is worth more than the same link in a sidebar — to the reader, because it arrives when it is wanted, and to the crawler, because body links carry more weight than boilerplate.

Can a page have too many links?

Yes, but the threshold is far higher than most people assume, and it is about usefulness rather than count. A page with two hundred links that a reader can scan — a directory, an index, a sitemap page — is fine. A page with twenty links where every second word is blue is not, because the text becomes unreadable and no single link stands out.

The genuine excess case is sitewide boilerplate: the same fifty links in the footer of every page. Those links count as internal links, technically, but they teach a crawler nothing about the relationship between two specific pages, because they appear on all of them. If your link audit shows a page is "well linked" only because of the footer, it is not well linked at all. Count body links separately from template links, and judge the page by the body links.

There is also a crawl-budget consideration on very large sites: every link is a URL a crawler may follow, and a site with millions of internal links can spend its crawl allowance re-walking the same navigation instead of reaching new content. For a site under a few thousand pages this is not a practical concern. For a large one, the fix is to stop linking to filtered, sorted, and paginated variants from every page, not to ration links on articles.

What to do

For a new page, link to at least two existing pages from the body, and link to the new page from at least one existing page — ideally the overview or article that a reader would arrive from. That is the whole rule for publishing, and it is also step seven of our pre-publish checklist. Two links out, one link in, every time, and orphans stop happening.

For an existing site, run the orphan check described above, then check the click-depth of your ten most important pages. If any of them is more than three clicks from the homepage, restructure the section rather than bolting on a homepage link. Then read the five pages that earn the most traffic and ask of each link whether a reader would want it: remove the ones that point nowhere useful, and add the ones a reader would have wanted but did not get.

Repeat the orphan check quarterly. Internal linking decays: pages get moved, sections get dropped, and links rot. A fifteen-minute check four times a year is the entire maintenance cost, and it catches the failure that no amount of content work can compensate for — a good page that nobody can find.

Limitations

The three-click rule is a heuristic from practice, not a measured threshold. Google has never stated that pages beyond three clicks are penalised, and deep pages do get indexed and do rank. The rule is useful because depth correlates with neglect — deep pages tend to be the ones nobody linked to, updated, or read — not because depth itself is a penalty.

Likewise, the advice here assumes a site small enough that a human can hold its structure in mind. On a site with hundreds of thousands of pages, internal linking is a data problem solved with crawl data and templates, not a writing problem solved with checklists. The principles are the same; the tooling is not.

Image Alt Text: What to Write and How Long

任宏涛 — Tue, 27 Oct 2026 00:00:00 +0000

The short answer

Alt text should say what the image does for a reader who cannot see it, in one sentence, in plain words. If the image is a chart, say what the chart shows. If it is a product photo, say what the product looks like. If it is purely decorative, leave the alt attribute empty. And keep keywords out of it: alt text is a description for people, not a place to store search terms.

That is the whole rule. The reason it needs a guide at all is that alt text is written for three audiences at once — screen reader users, search engines, and readers whose images fail to load — and the habits that serve one audience are sometimes wrong for the others. The rule above serves all three, which is why it has survived every change in how search engines work.

Who actually reads alt text

The first audience is people using screen readers, and they are the reason the attribute exists. A screen reader announces an image by reading its alt text aloud, in place of the image. A good description lets a blind reader follow the article; a missing or useless one — "image", "photo", a filename — leaves a gap in the middle of the sentence they were reading.

The second audience is search engines. Crawlers cannot see images, so alt text is one of the signals they use to understand what an image shows, and it contributes to how the page is understood. It also feeds image search: a descriptive alt text is part of why an image surfaces for a query about its subject. But its influence on ordinary web ranking is small, and anyone telling you alt text is a major ranking lever is overstating it.

The third audience is everyone, on a bad connection. When an image fails to load, the browser shows the alt text in its place. A reader on a slow network sees your description instead of a broken-image icon, and can decide whether the image was worth waiting for. This is the most common audience of all, and the one people forget, because they test pages on fast connections where images never fail.

How to write it

Describe the content and the function, not the file. Ask two questions: what would a reader miss if this image were removed, and what is the image doing in this spot? The answer to the first gives you the content; the answer to the second gives you the angle.

A chart showing search traffic doubling after a redesign: "Line chart showing weekly search visits rising from 400 to 900 over eight weeks following the redesign." A product photo of a red kettle: "Red stainless-steel kettle with a black handle, photographed on a white background." A screenshot of a tool's output: "The SERP preview tool showing a title truncated at 60 characters with the cut marked in red." Each one says what the image contains and why it is there.

The formula that works for most images is: what it is, plus the detail that matters, plus nothing else. "What it is" is the subject. "The detail that matters" is the one thing the surrounding text depends on — the number on the chart, the colour of the product, the error the screenshot shows. Anything beyond that is narration the reader did not ask for.

How long should it be?

One sentence, and usually under 125 characters. That number is not a rule from a specification; it is a practical limit from screen readers, several of which split or cut off alt text beyond roughly that length. A description that runs to three sentences will be truncated mid-thought for the very audience it was written for.

If one sentence cannot describe the image, the image is probably doing two jobs and should be split, or the description belongs in the visible text instead. A complex chart deserves a paragraph of explanation next to it, with the alt text carrying the summary: "Bar chart comparing load times before and after optimisation; full figures in the table below." The alt text points at the explanation; it does not try to be the explanation.

Long alt text has one more cost: it bores the listener. A screen reader user navigating a page hears every image announced, and a fifty-word description for a stock photo of a handshake is fifty words of their time spent on nothing. Brevity here is not style, it is respect.

Decorative images get an empty alt

Not every image needs a description. A divider, a background texture, a stock photo that adds mood but no information, an icon that sits next to a text label saying the same thing — these are decorative, and the correct alt text for a decorative image is an empty string: alt="".

Empty does not mean missing. An image with no alt attribute at all forces a screen reader to guess, and it usually guesses the filename — "hero-banner-final-v2.jpg" read aloud, in the middle of your article. An empty alt attribute tells the screen reader to skip the image entirely, which is exactly right for something that carries no information.

The test is simple: if you removed the image and nothing in the article became harder to understand, it is decorative. Be honest about this. Most images on most pages are decorative, and the reason so many sites have bad alt text is that their authors wrote earnest descriptions for images that needed none.

Common mistakes

Keyword stuffing. Alt text reading "cheap running shoes, best running shoes, running shoes sale, buy running shoes" is not a description, it is a keyword list, and it is read aloud to screen reader users in exactly that form. It also does not help rankings: search engines have treated keyword-stuffed alt text as a spam signal for years. Describe the image once, in words a person would use.

Starting with "image of" or "picture of". A screen reader already announces that the element is an image, so "image of a dog" is heard as "image, image of a dog". Start with the subject: "A dog sleeping on a porch."

Using the filename."IMG_4821.jpg" or "screenshot-2026-10-27-final.png" is not a description of anything. If the filename is the alt text, the alt text was never written.

Repeating the caption. If the image has a visible caption saying the same thing, the alt text should not repeat it word for word — a screen reader user hears it twice. Either shorten the alt text to the detail the caption omits, or, if the caption fully describes the image, leave the alt empty.

Describing text inside the image without transcribing it. If an image contains words — a screenshot of an error message, a photo of a sign — the alt text should include those words, because they are the content. "Screenshot of an error" does not help; "Screenshot showing the error message 'Payment failed: card declined'" does.

Alt text and the rest of the page

Alt text is one part of how a page presents its images, and it works alongside the other parts rather than replacing them. The file name should be readable too — red-kettle.jpg rather than IMG_4821.jpg — because file names are another signal about the image's subject, and because they are what people see when they save or share the file.

Captions, titles, and surrounding text all contribute. A caption can carry the context — where the photo was taken, who is in it — while the alt text carries the description. The two should complement each other, not duplicate each other.

And the same discipline applies to the tags that describe the page when it is shared. The Open Graph preview tool on this site shows what a link's share card will look like, including whether its image renders at all — a related check, because a share card with a broken image and a page with undescribed images are the same failure in two places: the image was treated as decoration when it was doing real work.

What to do

Audit the images on your ten most visited pages. For each one, ask whether it is decorative — if so, set an empty alt. If it is informative, write one sentence describing what it shows and why it matters, under 125 characters, without keywords and without "image of". If the image contains text, transcribe the words that matter.

Then make it part of publishing, not a cleanup project. The pre-publish checklist already includes an alt text step; the rule to attach to it is one sentence long, and it fits on the same line: describe what the image does, or leave it empty. Images added later inherit the habit, and the audit never needs repeating at scale.

Limitations

The 125-character guide is a practical limit from screen reader behaviour, not a specification, and different screen readers handle long alt text differently. Treat it as a default, and let a genuinely complex image exceed it when the alternative is leaving out information a reader needs.

Alt text also does not make an inaccessible image accessible on its own. A chart whose data matters needs a data table or a text summary alongside it; a diagram that explains a process needs that process explained in words. Alt text is the label on the image, not a substitute for the content the image carries.

nofollow vs sponsored vs ugc: Which to Use

任宏涛 — Tue, 27 Oct 2026 00:00:00 +0000

The short answer

Use rel="sponsored" for links you were paid for, rel="ugc" for links your users created, and rel="nofollow" for links you do not trust or cannot vouch for. That is the entire decision in one sentence. Everything else in this guide is about the cases where the answer is not obvious, and about what these attributes actually do now that Google treats all three as hints rather than commands.

The three values exist because one value was doing three jobs badly. For years, nofollow was the only option, so it got used for paid links, for comment links, and for untrusted links alike, and nobody reading the markup could tell which was which. Splitting them apart was a labelling fix: the same link, described accurately.

What each one means

sponsored means money changed hands. Any link that is part of an advertisement, a sponsorship, or a paid placement — including a product a company sent you for free in exchange for a link — should carry rel="sponsored". This is the one with the clearest rule behind it, because paid links that pass ranking credit are a manipulation of search results, and search engines and regulators both treat undisclosed paid links as a violation. If a link exists because someone paid for it, mark it.

ugc means a user wrote it. Links in comments, forum posts, reviews, and any other content your visitors contribute should carry rel="ugc". The point is to separate the links you chose from the links your users chose. You did not vet them, you did not endorse them, and you should not have to: the attribute says the link came from a user, and the search engine can weigh it accordingly.

nofollow means you do not vouch for it. Use it for links to pages you do not trust, or where you have no basis to endorse the destination — a link in a guest post you did not fully review, a link to a site you have not checked, a link you are including for completeness rather than recommendation. It is the general-purpose "no endorsement" marker, and it is also the fallback when none of the other two fits.

The decision, as a table

The link is…	Use	Why
Paid, sponsored, or exchanged for a product	`sponsored`	Money must be disclosed; unmarked paid links are a violation
Written by a user: comment, forum post, review	`ugc`	Separates your editorial links from your users' links
One you do not trust or have not vetted	`nofollow`	Withholds endorsement without deleting the link
A normal editorial link you chose	Nothing	An ordinary link is an endorsement; marking it would be wrong
Paid and user-written at once	`sponsored ugc`	The values combine; use both

Read the last row carefully, because it answers the question people ask most: yes, the values can be combined. rel="sponsored ugc" is valid, and so is rel="nofollow sponsored". They are labels, not radio buttons, and a link can truthfully carry more than one.

They are hints now, not commands

Since 2019, Google treats all three values as hints rather than directives. Before that, nofollow was an instruction: do not follow this link, do not pass ranking credit through it. Now it is a suggestion that Google may follow or ignore, depending on its own judgement of the link and the page.

In practice this changes less than it sounds. Google still generally honours the hint, and a page full of marked links does not pass credit the way an unmarked page does. What changed is that Google reserves the right to use a marked link as a discovery signal — to find a new page through it, for example — even when it does not pass ranking credit. So marking a link no longer guarantees it is invisible to crawlers. If a link must not be followed at all, the mechanism is robots.txt, not a rel attribute.

The other practical consequence is that mislabelling is now less catastrophic than it was. A paid link marked ugc instead of sponsored is still wrong — the disclosure is inaccurate — but it is not the total loss of control it would have been under the old directive model. Fix it anyway. The attribute is a statement about the link, and statements should be accurate.

Common mistakes

Marking every outbound link nofollow. Some sites do this as a blanket policy, on the theory that it "preserves" ranking credit. It does not preserve anything — credit is not a substance that leaks out of links — and it makes the site's markup dishonest: every link claims no endorsement, including the ones the author genuinely recommends. Mark links by what they are, not by policy.

Marking internal links. The three values describe how a link should be treated by search engines, and they are meant for links to other sites. Putting nofollow on your own internal links does not concentrate authority on the remaining pages; it just makes your own site harder to crawl and understand. Internal links should almost always be plain links.

Using nofollow for paid links. It was the old habit, and it is now the wrong label. A paid link is sponsored, and calling it nofollow hides the reason it exists. Google has said explicitly that sponsored is the correct value for paid links, and using the wrong one is a disclosure failure, not a harmless synonym.

Forgetting that comments need it. A comment section with unmarked links is an open invitation to spam, because every posted link passes endorsement by default. If your site accepts user content, the ugc attribute should be applied by the template, not by hand — one line in the rendering code, not a decision per comment.

Treating the attribute as a security measure. Marking a link does not make its destination safe, does not stop users clicking it, and does not prevent crawlers from ever visiting it. It is a statement about endorsement and ranking credit, nothing more. A link to a malicious site should be removed, not marked.

What to do

Audit your templates first, because most links on a site are generated, not written by hand. Check that comment and forum templates add ugc automatically, that any advertising or sponsored-content template adds sponsored, and that editorial content templates add nothing. One template fix covers every future link; one manual fix covers one link.

Then check the links you wrote by hand: affiliate links, sponsored mentions, and product links in reviews. Affiliate links are paid links — the commission is the payment — so they take sponsored, and the same applies to a product sent to you for review. If you are unsure whether a link counts as paid, ask whether the link would exist without the payment. If the answer is no, mark it.

Finally, do not go back and re-mark old links in bulk unless they are paid links, because mislabelled paid links are the one case with real consequences. Ordinary editorial links that carry a stray nofollow from an old blanket policy are worth cleaning up when you touch the page anyway, but they are not worth a dedicated migration. The pre-publish checklist includes a link review step; add the rel question to it, and the problem stops recurring.

Limitations

Google's treatment of these values as hints means the effect of marking a link is not directly observable from outside. We cannot measure, for a given link, whether credit passed or not, because that is an internal judgement. What we can verify is the labelling: whether the markup accurately describes the link. That is the part this guide is about, and it is the part you control.

Other search engines and AI crawlers may treat these values differently, and none has published a complete account of how. The values are a web standard for describing links, so using them accurately is correct regardless of which system reads them — but do not assume every system reads them the same way Google does.

I built a tax estimator for freelancers because QuickBooks is overkill

任宏涛 — Wed, 21 Oct 2026 10:50:55 +0000

Freelancers: you don't need QuickBooks to stay tax-ready.

You need to know how much to set aside each quarter.

Built a tool that does exactly that — upload a CSV, get your quarterly tax number in ~5 minutes. $9/mo, 7-day trial.

https://sololedger-1us.pages.dev

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.

What 61 Homepages Actually Ship in JSON-LD

任宏涛 — Tue, 22 Sep 2026 00:00:00 +0000

How this was measured

On 2026-09-23 we fetched the homepage of 78 well-known domains and extracted every <script type="application/ld+json"> block from the response. 61 returned a usable page — 42 over a direct connection and 19 over a local proxy. Of those 61, 32 contained at least one JSON-LD block.

One caveat governs everything below, so it belongs at the top rather than the bottom: this measures what is present in the server-rendered HTML. A page that injects its structured data with JavaScript will look empty here even though a browser — and Google, which renders — would see it. Single-page applications are the obvious case. So when this article says a site "ships none", read it as "none in the initial HTML response", which is a different and weaker claim.

For the sites where we did find markup, that caveat disappears: everything about blocks, @graph, @id and node types is measured on markup that was actually present.

Finding 1: about half ship nothing in the HTML

29 of the 61 homepages contained no JSON-LD block at all. The list includes github.com, youtube.com, wikipedia.org, w3.org, mozilla.org, linkedin.com, x.com, spotify.com, npmjs.com, nodejs.org, kubernetes.io, mit.edu, stanford.edu, khanacademy.org, theguardian.com, slack.com, notion.so, trello.com, tumblr.com, vimeo.com, archive.org, wikimedia.org, digitalocean.com, squareup.com, uber.com, cdc.gov, go.dev, rust-lang.org and developer.mozilla.org.

Some of those are certainly JavaScript-rendered and will have markup in a browser. But wikipedia.org is not a JavaScript application, and neither is w3.org or github.com — those responses were 119KB, 51KB and 576KB of ordinary server-rendered HTML with no structured data anywhere in them.

The honest conclusion is narrower than "half the web has no structured data" and more useful than nothing: shipping JSON-LD is a choice that a large share of serious sites have not made, and it is not a precondition for ranking.

Finding 2: 14 sites still ship markup for a retired feature

This was the most surprising result. Google retired the sitelinks search box on 21 November 2024 — the search field that used to appear under a brand's result. The markup that powered it, a SearchAction on the WebSite node, now produces nothing.

Fourteen of the 32 sites with JSON-LD still carry it: cnn.com, forbes.com, walmart.com, atlassian.com, zoom.us, pinterest.com, docker.com, python.org, screamingfrog.co.uk, yoast.com, cloudflare.com, heroku.com, airbnb.com and who.int.

Two of those are SEO tool vendors. That is the interesting part: this is not a case of amateurs leaving stale markup around. It is a case of markup that was correct when it was written, that nothing broke when it stopped mattering, and that no tool flags because it is still valid schema.org. There is no error, no warning, and no rich result — just a few lines of JSON that no longer do anything.

It is worth being fair about this: leaving it in place costs nothing measurable. We are not suggesting the markup is harmful. The point is that it is invisible dead weight, and the only way to notice is to know the feature was retired — which is exactly the kind of thing that a site audit will never tell you.

If you are auditing your own markup, this is the check that pays: is any of it aimed at a feature that no longer exists? The schema generator on this site does not emit SearchAction for that reason.

Finding 3: a single block is the norm, and @graph is the minority

Of the 32 sites with markup, 24 used exactly one block, four used two, three used three, and one used four. So the "many small blocks" pattern that our @graph guide warns about is not actually the common shape — one block is.

Within that single block, however, the split matters. Only 13 of the 32 (41%) use a @graph array. The rest put a single node at the top level.

The 13: gitlab.com, atlassian.com, zoom.us, asana.com, docker.com, twitch.tv, moz.com, screamingfrog.co.uk, yoast.com, searchenginejournal.com, stripe.com, netlify.com and heroku.com.

Look at that list again. Four of the thirteen are SEO tool vendors or SEO publications — Moz, Screaming Frog, Yoast and Search Engine Journal. When the people who build the tooling converge on a pattern, that is usually worth more than a spec reading, and it is consistent with the argument in the @graph guide: one connected graph beats several disconnected blocks.

Finding 4: most markup is boilerplate

Twenty of the 32 sites ship only generic node types — Organization, WebSite, WebPage, ContactPoint, PostalAddress — with nothing specific to the page being viewed.

The type frequency across all 32 tells the same story. The most common types were PostalAddress (33 occurrences), Organization (25), Place (24), WebSite (20) and ImageObject (20). BreadcrumbList appeared 6 times. SoftwareApplication 6 times. VideoObject 6 times.

More addresses than web pages. For a homepage that is defensible — the homepage is where the organization describes itself. But it means that on most of these sites, the structured data says "here is a company" and never says "here is what this particular page is about".

Finding 5: the pattern at full size

stripe.com packs 54 nodes into a single @graph — by a wide margin the largest we found, and more than the next three sites combined.

That is the @graph pattern doing what it is for. Fifty-four connected nodes with @id references resolve to one coherent description of the site rather than fifty-four independent assertions that must agree with each other by hand.

What we did not find: almost no dangling references

Our @graph guide warns that referencing an @id which is never defined causes the property to be silently ignored. We expected to find this in the wild.

One site out of 32 — paypal.com, with a single reference to https://www.paypal.com/c2/home#website that no node defines.

Two other things we expected and did not find: zero JSON parse failures across every block we extracted, and no site shipping markup in more than four blocks. Invalid JSON-LD and block sprawl both turn out to be much rarer than the advice would suggest.

This is the second time in two surveys that a widely repeated warning did not appear at all in a sample of this size. That is not an argument for ignoring the warnings — a dangling reference is still a bug — but it is an argument for checking how often the thing you are worried about actually happens before you spend a week refactoring.

What to check on your own markup

Is any of it aimed at a retired feature? SearchAction is the one to search for today. Check the markup against the current list of supported rich results rather than against a tutorial you followed in 2023.

Does it say anything about this page? If every page on your site emits the same Organization and WebSite nodes and nothing else, the markup is describing your company and not your content.

Is it one connected graph or several disconnected blocks? Neither is an error. One is easier to keep consistent.

Does every @id you reference exist on the page? Extract the defined @id values and the referenced ones and compare the lists. It takes a minute by eye on a page with under ten nodes.

Limitations

The sample is 61 reachable homepages chosen by hand to span categories — representative of well-known sites, not of the web. Homepages only: article, product and FAQ markup lives on inner pages and is not measured here.

The server-rendered caveat is the big one. Any JavaScript-injected markup is invisible to this method, so the true rate of sites using structured data is certainly higher than 52%. The findings about @graph, node types and SearchAction are drawn only from markup we actually retrieved, so they are unaffected — but the headline number is a floor, not a rate.

Finally, this is a single-day snapshot of pages that change constantly.

Reproduce it

The extraction script and the domain list ship with this site and run in about two minutes. It writes the extracted JSON-LD for every domain, so each claim above can be checked against the markup itself rather than our summary of it.

If a row is wrong, the markup settles it. Corrections via the contact page — and if you know why the sitelinks search box markup is still so widespread two years after retirement, we would like to hear that too.

Link rel in the Wild: 54 Homepages

任宏涛 — Tue, 22 Sep 2026 00:00:00 +0000

How this was measured

On 2026-10-16 we requested the homepage of each of the same 78 hand-picked domains our other surveys use — news, commerce, SaaS, developer tooling, social, streaming, reference, SEO, education, finance, cloud, local and government — and parsed every <a> tag in the HTML we got back. Each request identified itself as a survey crawler and was attempted directly first, then through a local proxy; 56 domains answered on the direct path and 22 needed the proxy.

63 of 78 returned a readable homepage (80.8%). The other 15 are counted as undecidable, not as absent: 202 from amazon.com and booking.com, 403 from ebay.com, stackoverflow.com, npmjs.com, yelp.com and nih.gov, 406 from uber.com, and no response at all from nytimes.com, reuters.com, washingtonpost.com, etsy.com, quora.com, searchengineland.com and coinbase.com.

Nine of the 63 then had to be excluded for a different reason: their HTML contained fewer than 20 links , which means what we fetched was a JavaScript shell rather than a page — reddit.com 0, pinterest.com 18, tumblr.com 4, youtube.com 14, twitch.tv 0, archive.org 0, khanacademy.org 0, paypal.com 9 and airbnb.com 14. That leaves 54 homepages carrying 10,121 anchors , median 171 links each, ranging from 20 to 649.

Four parsing decisions shaped every number below, and each one changed an answer. Internal versus external is decided by registrable domain, not by hostname : docs.docker.com and www.docker.com are one site, and screamingfrog.co.uk has a three-label registrable domain, not two. Non-HTTP schemes are excluded before anything is counted — 144 in-page fragments, 37 anchors with no href at all, 8 mailto:, 8 tel: and 5 javascript: links are not outbound links. Attribute values do not have to be quoted , and a parser that insists on quotes silently discards them. And when a tag carries two rel attributes, only the first one counts , which is the HTML rule and turns out to matter here.

Finding 1: the attribute everybody argues about is the one nobody uses

Of the 1,087 outbound links across these 54 homepages, 41 carry rel="nofollow" — 3.8%. More telling is the site-level count: 5 of 54 homepages nofollow a single outbound link. Those five are ahrefs.com (17 of its 37 outbound links), digitalocean.com (9 of 12), shopify.com (7 of 29), semrush.com (6 of 10) and x.com (2 of 2). Every other homepage — bbc.com, netflix.com, cloudflare.com, stripe.com, wikipedia.org, cdc.gov — links out to other domains with nothing on the tag.

20 of 54 homepages put no rel on any outbound link at all , and one, spotify.com, has no outbound links on its homepage whatsoever. If you have been told that marking external links is standard practice, this sample says otherwise: it is a practice a minority of sites apply, unevenly, and three of the five that do apply it are SEO or marketing companies.

The pooled percentages are almost useless here, and that is worth stating plainly. zoom.us alone contributes 270 of the 1,087 outbound links, 262 of them pointing at zoom.com. A single site's link structure can move any pooled number by a quarter, which is why every rate in this article is reported per site as well as pooled.

Finding 2: sponsored has one user, and it is not an affiliate site

Exactly one homepage in 54 uses rel="sponsored", and it is nodejs.org. It uses it eight times, on eight sponsor buttons — digitalocean.com, nodesource.com, vercel.com, herodevs.com, cloudflare.com, tuxcare.com, macstadium.com and microsoft.com — each carrying rel="sponsored noopener", target="_blank" and a utm_source=nodejs-website parameter. That is the textbook case for the attribute: paid placement, disclosed in markup, with the tracking parameters sitting right next to it.

Which makes the absence everywhere else hard to read as anything but under-use. Homepages of this kind are exactly where sponsored logos and partner badges live, and 53 of 54 mark them with nothing.

rel="ugc" appears zero times. That number needs a caveat before anyone quotes it: ugc exists for user-generated content — comments, forum posts, profile fields — and a corporate homepage is the one page type that reliably has none. Zero here is evidence about where we looked, not about whether the attribute is used. It is the reason this survey reports the homepage rate for ugc and refuses to generalise from it.

One homepage also uses rel="external" (mozilla.org). It is not something Google reads; it is a convention, sometimes used by scripts that style or handle outbound links.

Finding 3: what sites actually write is noopener, and it stopped being an SEO decision

The most common token by a wide margin is not an SEO signal at all. noopener appears on 299 outbound links across 26 of the 54 homepages ; noreferrer appears on 163 across 18. The two are paired on 146 links, noopener is written alone on 153, and noreferrer alone on 17.

None of that is about ranking — it is the window.opener tabnabbing fix, and it is now largely redundant. MDN's documentation for <a> states that setting target="_blank" implicitly provides the same rel behaviour as setting rel="noopener" in newer browser versions. The implicit behaviour does not extend to noreferrer , so if the point is to keep the referring URL out of the request, that still has to be written explicitly.

Which reframes the 181 links in this sample that open a new tab without either token. 752 links across 42 homepages carry target="_blank"; 181 of them, on 23 sites, have no noopener and no noreferrer , and 58 of those 181 point off-site. On a modern browser that is a non-issue. On an old one, or if you wanted noreferrer, it is not.

Finding 4: two sites write noopener in a form the browser cannot read

Counting tokens rather than trusting the attribute is what surfaced these, and both were verified against the raw HTML before being written down.

screamingfrog.co.uk writes rel=”noopener” with typographic quotation marks — U+201D, the curly character a word processor or a copy-paste from a rich-text editor produces — on four social links in its footer. The value is not the token noopener; it is a nine-character string containing it. The browser parses the attribute fine and then matches nothing. This is an SEO software vendor's own site, and it is the kind of defect no validator flags, because the markup is valid.

moz.com writes two rel attributes on the same tag , three times: <a rel="author" href="…" target="_blank" rel="noopener noreferrer">. HTML takes the first and ignores the second, so those three links open a new tab with rel="author" and nothing else. The fix is one attribute with all three tokens, and the reason it went unnoticed is that the HTML looks correct to a human reader.

Two smaller ones in the same family: 145 links across atlassian.com, slack.com and developer.mozilla.org carry rel="" — an empty value, almost certainly a framework rendering an empty prop. It does nothing. And harvard.edu uses rel="home" on its logo link, a value that has been obsolete for years.

Finding 5: five sites put nofollow on their own links

43 internal links across 5 homepages carry rel="nofollow" — links pointing at the same registrable domain they appear on. The counts: digitalocean.com 16, x.com 14, docker.com 5, ahrefs.com 4 and stanford.edu 4.

Read the actual tags and the pattern splits in two. digitalocean.com nofollows footer furniture — /press, /leadership/executive-management, /currents, /open-source, plus store.digitalocean.com, status.digitalocean.com and ideas.digitalocean.com. x.com nofollows its own legal and help pages — /tos, /privacy, help.x.com, about.x.com, careers.x.com, each with rel="noopener noreferrer nofollow". docker.com nofollows its own installer downloads, ahrefs.com nofollows help.ahrefs.com and its own /podcast, and stanford.edu nofollows its copyright, trademark and non-discrimination pages.

Some of that is defensible — nofollow on a login or a legal page is a way of saying "do not spend crawl budget here" — and some of it looks like a template applied to a whole footer. Either way it is a decision being made about internal crawl paths, and it is being made on five of the most heavily engineered homepages in the sample rather than by accident.

What to ship

Stop nofollowing outbound links by default. Five of 54 homepages do it at all, 20 mark nothing, and Google has treated these values as hints rather than directives since 2019. Marking every external link was never the norm this sample reflects.

Do use sponsored where money changed hands. nodejs.org is the only site here that does, and it is the clearest, cheapest signal available: one attribute on the links you are already tagging with UTM parameters.

Put ugc where the user-generated content is. Comment templates, forum threads, review forms — not the homepage. Zero of 54 homepages use it because none of them have comments on the homepage.

Keep noopener only if you need old-browser coverage, and treat noreferrer as the part that still counts. Modern browsers imply the former for target="_blank"; they do not imply the latter.

Audit for the two broken patterns, because no tool warns you about either. Grep the rendered HTML for curly quotes inside attribute values, and for tags with rel twice. Both are valid HTML that does nothing — grep -o 'rel=[^ >]*' page.html | sort | uniq -c | sort -rn shows the first in one line.

To write the head tags for a new page without any of them drifting apart, the meta tag generator produces the title, description, canonical and robots tag from one input, and the robots.txt tester covers the file that governs crawling rather than link-level signals.

Limitations

Homepages only, and only 54 of them. A homepage is where navigation and footer link sets dominate: the median homepage here has 171 links and only 13 outbound ones, and outbound links are a median 8.2% of everything on the page. Article pages, category pages and comment threads have completely different link profiles, and ugc in particular lives there.

Server-rendered HTML only. Nine otherwise-readable homepages had to be dropped because their HTML was a JavaScript shell, and any link added after load is invisible to this method. The sample is biased towards sites that render on the server, which is the same bias our heading and favicon surveys carry.

The internal/external split is mechanical. We compare registrable domains, so zoom.us linking to 262 zoom.com URLs is counted as outbound even though it is one company, and a link to a site's own CDN or a subsidiary counts as external. That single site contributes a quarter of the pooled outbound total.

One snapshot, one user agent. Everything was fetched on 2026-10-16 with a crawler identity. WAFs answer differently per client, and while every verdict in this article was checked against the raw tag, the pages themselves were not re-requested with a browser user agent.

We counted attributes, not intent. A rel that a framework renders but a script strips, or one added client-side, lands in the wrong bucket, and we cannot tell from HTML which links anyone considers paid.

Reproduce it

The script and the shared domain list ship with this site. node scripts/survey-link-rel.mjs fetches all 78 homepages and stores them; --report re-parses and re-derives every number from the stored HTML without touching the network, which is how the parsing fixes were applied after the fetch; --evidence prints the original <a> tag behind every verdict — that is what confirmed the curly-quoted noopener, the duplicated rel and all eight sponsored links. Our robots.txt, canonical, AI crawler and indexing directive surveys run the same domain list from other angles.

Why Google Won't Index Your Page: A Checklist

任宏涛 — Tue, 22 Sep 2026 00:00:00 +0000

Two problems that look identical and are not

Almost every "my page is not indexed" complaint is one of two things, and they need opposite responses.

A code fault is something wrong with the URL or the page. It is fixable today, and once it is fixed the page becomes eligible. A trust gate is Google having fetched the page and decided not to spend index space on it yet. There is nothing to fix, because nothing is broken — and this is where most advice sends people in circles.

Order matters because the two produce the same symptom in Search Console, and the fix for one does nothing for the other. Re-requesting indexing on a page in a trust gate wastes your one lever. Rewriting the content of a page blocked by a noindex tag is worse than wasted, because the actual problem is still sitting there.

Step 1 — read the status code, not the page

A page that renders in your browser is not proof of anything. Ask the server instead:

curl -sS -o /dev/null -w "%{http_code}" https://example.com/page

What the answer tells you:

404 or 410 — the page is not indexed by design. Either the URL is wrong or it was deliberately removed. Nothing else in this guide applies.
5xx — the server is failing. Google backs off and retries later; it will not index a page it cannot fetch. Fix the server first.
301 or 302 — you are looking at a different URL from the one you think. Follow the redirect and diagnose the destination.
200 — good, but keep reading, because 200 is where the real traps live.

The trap that hides inside a 200 is the soft 404 : the server reports success and the content is an error page. Our robots.txt survey caught exactly this on two of 78 well-known domains — khanacademy.org and cdc.gov answered 200 with an HTML error page instead of a robots file. A monitor watching status codes sees nothing wrong and a browser shows a page. If your unindexed URL returns 200 and reads like an error, you have your answer.

Step 2 — is it blocked?

Two mechanisms can block indexing, and they are not the same mechanism:

robots.txt — a Disallow line stops the crawl. Note that it stops the fetch, not the indexing of a URL Google already knows about from links elsewhere.
A noindex meta tag or X-Robots-Tag header — this stops indexing even when the page is crawled normally.

One combination costs people weeks: a robots.txt Disallow and a noindex on the same page. The disallow prevents Google from fetching the page, so Google never sees the noindex, so the URL can still be indexed from links pointing at it. You then remove the noindex, observe no change, and conclude the tag was never the problem. The order to undo it is: remove the Disallow first, let Google fetch the page, confirm it reads the noindex, and only then remove that.

You can test the first of these with our robots.txt tester. For the header, one curl is enough: curl -sSI https://example.com/page | grep -i x-robots-tag. And note that a page with no robots meta at all is normal — index, follow is the default, so its absence is not a fault.

Step 3 — can it be discovered?

Google cannot index a URL it never finds. Three ways a page stays invisible:

It is not in your sitemap. Check that the URL appears in sitemap.xml — and that the URL listed there actually exists. A sitemap full of 404s is a signal of neglect rather than of coverage.
The sitemap is not declared. Listing it in robots.txt lets a crawler find it without being told twice.
Nothing links to it. This is the most common cause of a page that is technically perfect and never gets indexed. A page with no internal links is an orphan, and orphans depend entirely on the sitemap being read.

That last one is the same class of omission our canonical survey found on 11 of 55 famous homepages: the tag was simply absent. Nobody forgot on purpose. Omission is the default state of a site nobody audits.

Step 4 — is it a duplicate?

If the page is crawlable, discoverable and unblocked, the next question is whether Google treats it as a second copy of something else. The canonical tag is the instruction that decides this, and the mistake that matters is comparing it against the wrong URL.

In our canonical survey, 43 of 55 homepages redirected at least once before serving content. If you compare your canonical against the URL you typed rather than the URL you were finally served, you will conclude you have a cross-domain canonical problem when you do not. Compare against the final URL after redirects. Then check that the canonical target itself returns 200 — two of the 43 we tested pointed at URLs that did not, and nothing warns you when that happens.

Three more duplicates worth ruling out: the http and https versions of the page, the www and non-www versions, and any tracking parameters that create a second address for the same content.

Step 5 — is the content actually there?

If the page is a single-page app, the HTML Google receives may contain almost nothing. Curl the URL and read the raw source rather than the rendered page. If the body is an empty container and a bundle of script tags, that is what a crawler may be evaluating.

This is not hypothetical. Two of the homepages in our SERP snippet survey returned client-rendered shells with no title in the served HTML at all. Google can render JavaScript, but it does so on a second pass, and a page that needs rendering is a page that is slower and less certain to be evaluated.

Step 6 — now it is a trust gate, and there is nothing to fix

If every check above passed, the page is eligible and Google is choosing not to index it yet. Search Console describes this in two ways:

Discovered — currently not indexed : Google knows the URL exists and has not fetched it yet.
Crawled — currently not indexed : Google fetched it and judged it not worth index space at this point.

Neither is a defect, and neither is a bug you can patch. The usual reasons are thin content, no internal links, a brand-new domain with no authority, or content close enough to pages that already exist that Google does not need another copy of it.

What actually moves it: content clearly more useful than what is already indexed, internal links from pages that are themselves indexed, genuine external links or mentions, and time. What does not move it: requesting indexing repeatedly, resubmitting the sitemap repeatedly, or rewriting the page for the third time.

We went through this on our own site. A batch of pages sat in "Crawled — currently not indexed" while every technical check passed: 200 status, self-referencing canonical, index and follow, well over a thousand words each. There was nothing to fix. They drained on their own within days. The useful conclusion is not "wait and hope" — it is that when all five steps above pass, the correct action is to stop working on that page and go make the rest of the site better.

What "Request indexing" does, and does not do

It queues a fetch. That is the whole of it. It is worth using on a brand-new URL, or on a page you have just fixed, because it shortens the wait for the next crawl.

It is not worth using on a page that has already been crawled and judged. Requesting indexing does not override a quality decision, there is a practical limit on how often you can use it, and spending it on a trust gate burns the one lever you have for a genuine fault.

The order, in one table

#	Check	If it fails	Fixable by you
1	Status code	404, 410, 5xx, or a soft 404	Yes, today
2	robots.txt, noindex, X-Robots-Tag	Blocked from crawl or from index	Yes, today
3	Sitemap and internal links	Undiscoverable, or an orphan	Yes, today
4	Canonical and duplicates	Consolidated into another URL	Yes, today
5	Content present in the served HTML	Empty shell as seen by a crawler	Yes, today
6	All of the above passed	A trust gate	No — content, links and time

The point of working in this order is that you stop at the first failure, and you stop entirely at step 6. Most people start at step 6 and work backwards, which is why the advice to "just keep improving the content" gets applied to pages that were never crawlable in the first place.

DEV Community: 任宏涛

How AI Search Engines Choose What to Cite

The short answer

First, the page has to be found and read

Second, the answer has to be quotable

Third, someone else has to vouch for the page

What this looks like on SerpPrism

What does not help

What to do on your own site

Limitations

How Long Should a URL Slug Be?

The short answer

What a slug is, precisely

The working rule

What to leave out

Changing a slug: the 301 rule

Common mistakes

What to do

Limitations

How Many Internal Links Should a Page Have?

The short answer

Why no number exists

The three-click rule

Orphan pages are the real problem

Anchor text: say where the link goes

Can a page have too many links?

What to do

Limitations

Image Alt Text: What to Write and How Long

The short answer

Who actually reads alt text

How to write it

How long should it be?

Decorative images get an empty alt

Common mistakes

Alt text and the rest of the page

What to do

Limitations

nofollow vs sponsored vs ugc: Which to Use

The short answer

What each one means

The decision, as a table

They are hints now, not commands

Common mistakes

What to do

Limitations

I built a tax estimator for freelancers because QuickBooks is overkill

Nine SEO checks to run before you publish a page

The problem with SEO checklists

1. Does the page have exactly one h1?

2. Do heading levels descend without skipping?

3. Is the title tag specific to this page?

4. Will the description survive truncation?

5. Does the canonical point at itself?

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

7. Are the internal links real and useful?

8. Do images have dimensions and alt text?

9. Does the structured data describe this page accurately?

What is deliberately not on this list

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

Method, and the two counting rules that changed the numbers

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

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

Finding 3: only 23% declare image dimensions

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

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

What to check on your own tags

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

The pattern almost everyone starts with

What @id actually does

The shape that works

Three ways this goes wrong

Dates deserve their own section

Checking your markup

What 61 Homepages Actually Ship in JSON-LD

How this was measured

Finding 1: about half ship nothing in the HTML

Finding 2: 14 sites still ship markup for a retired feature

Finding 3: a single block is the norm, and @graph is the minority

Finding 4: most markup is boilerplate

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

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

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

What `@id` actually does