A page people can finish, and a passage a machine can lift
Google still sends humans. It also now lifts sentences into overviews, featured snippets, and “people also ask”. Those lifts are not a mystery format. They are short passages that answer one question in plain language, sit under a heading that matches the query, and do not hide the claim in a metaphor. If your service page opens with “we drive synergy across the digital landscape”, nothing trustworthy has a sentence to quote. If it opens with what the work is, who it is for, and what you will not do, a person can use it — and a crawler has something to cite.
This is not a trick for ranking overnight. It is how you write if you want the page to stay useful when someone lands from search, from a colleague’s forward, or from an overview that showed two sentences and a link. The sentences have to be true. Dated. Narrow. The rest of the page then earns the click by being the longer, honest version.
Passage-level answers, not a fog of keywords
A passage-level answer is two to five sentences under a heading that a person would actually type or speak. “What is a Core Web Vital?” gets a definition, the three names, and when they matter. It does not get a paragraph about your awards. The heading is the question. The first paragraph is the answer. The following paragraphs are the caveats and the “what to do on Tuesday”. That order is how both a hurried operations lead and a citation engine find the claim.
Write the answer as if someone will paste it into a slack thread. If you would be embarrassed to see only that paste, the passage is not ready. Slogans fail this test. So do hedges that never land (“it depends” with no following rule). “It depends” is allowed when the next sentence states on what — public page versus logged-in app, Tally still in place versus a new book of record, one branch versus three.
One page can hold several passages. A pillar on the knowledge hub should. A blog post can hold one or two and then tell a story. Do not force every URL to be an encyclopedia. Do not force every URL to be a narrative. Pick the job of the URL, then write the passages that job needs.
Dates, and other things a quote needs around it
A claim without a time is how you get cited for a number you no longer stand behind. “Field data in Search Console is what Google uses for Core Web Vitals” is a claim you can date. “Lighthouse on an office fibre line is a hint, not the report that matters” is another. When the underlying product changes — INP replacing FID, a new overview layout — the page should say when you last checked. A “last reviewed” line is not bureaucracy. It is how a citation stays honest.
Plain claims beat decorated ones. “We help you grow” is not a claim. “Public service pages that already have impressions should be in the good mobile field bucket, or you should know why not” is a claim. The second sentence can be quoted. The first can only be ignored. If you cannot write the second kind without inventing a case study, you do not yet have an article. You have a brochure paragraph looking for a home.
Do not invent client names or rupee totals to make a passage feel specific. Specificity comes from the job: the warehouse phone, the Tally company, the mid-range Android in Kerala traffic, the URL that already has impressions. Those are real. A fake case study is a citation you will regret.
How /knowledge and /blog should differ
On this site the split is deliberate. Knowledge is the shelf: definitions, comparisons, checklists, pages you would send a buyer who asked a named question. The blog is the bench: what we are thinking this month, a post-mortem, a seasonal warning, an argument that is allowed to be dated. Both should be quotable. They should not try to be the same document.
| Knowledge | Blog | |
|---|---|---|
| Job | Answer a standing question | Argue or narrate a moment |
| Shape | Passages, tables, checklists | A lead, a story, a few passages |
| Date | Last reviewed; still true next year | Published this Monday; may age |
| Voice | Definition first, then caveats | Allowed to start from a stall or a season |
| Failure | A page that never answers the H2 | A diary entry with no claim anyone can use |
If you find yourself rewriting a knowledge guide as a blog post so it “feels fresh”, stop. Link the guide. Use the blog for the thing the guide cannot do: a July post-mortem, a festival warning, a change in how overviews quote pages. Duplicate URLs that say the same thing in a slightly warmer tone are how you split authority and confuse the person who landed.
The other failure is using the blog as a dumping ground for keyword pages. “What is MVP development?” already has a home. A Monday essay can point at it and then talk about why the last MVP was not one. That is a blog job. Repeating the definition for two thousand words is not.
What a knowledge page owes the reader
A knowledge URL should let someone leave after the first passage if they only needed the definition — and stay if they need the caveats. That means the first heading block answers the query. It means internal links go to the next decision, not to a loop of the same idea. It means you do not open with the company story. We put that story on About. The knowledge shelf is for the work.
It also means you accept boredom. “An API is a contract, not a screen” is boring. It is also the sentence a non-developer can take into a vendor meeting. Knowledge pages are allowed to be boring if they are exact. Blog pages are allowed to be warmer if they still contain one exact passage. Mixing those jobs produces a blog that never finishes a thought and a knowledge base that sounds like a campaign.
When we add a knowledge article, we write the quick answer as if it will be the only thing a crawler lifts. Then we write the rest so a human is not stranded. If those two disagree, the page is not ready. The lifted sentence will be the one people remember. It has to be one we would still sign.
What a blog page owes the reader
A blog URL should say why this week. July is when last quarter’s build is either in use or quietly abandoned. That is a reason to write about stalled projects, not a reason to republish the cost guide. A blog post can use “we” and a Monday date. It should still contain one passage you would allow Google to quote without a call to legal: a rule, a distinction, a refusal.
It should also end. Knowledge pages can be long because the question is standing. Blog pages that wander through every related service are not generous. They are unsure. Link the service. Link the guide. Stop. This post links web development because public pages that must rank are a website job, including the vitals work. It does not try to be the vitals explainer.
Speed and quoteability are different jobs that meet on public URLs
A beautiful passage on a page that takes six seconds to show its heading is a passage fewer people will read. On public marketing and article URLs, Core Web Vitals are part of making the quote available: the main content has to appear, the layout cannot jump as the reader starts the paragraph, the tap on “Call” cannot hitch behind a chat widget. That is a build concern, not a monthly PDF from a retainer.
Vitals do not make a hollow page citeable. A green LCP on a slogan is still a slogan. Do the words first. Then make sure a phone in traffic can see them. Internal tools behind a login can ignore this section. Staff will complain in words, not in Search Console. Public pages cannot ignore it if you want the passage to be seen as well as indexed.
Image dimensions, third-party scripts after first paint, fonts that do not shove the heading — those are how a quoted paragraph stays on screen. They belong in the website build, not in a separate “SEO package” that only reruns Lighthouse. If you are briefing a public site, put both in the definition of done: the passages, and the field behaviour on the URLs that already have impressions.
A checklist for a page you want quoted
- One H2 that matches a question a person would ask. The first paragraph answers it in plain words.
- A date or a “last reviewed” where the claim can rot (metrics, products, tax rules).
- No invented clients or totals. Specificity from the job, not from fiction.
- A table or list if the answer is a comparison. Prose if the answer is a rule.
- A link to the standing guide if this URL is the timely argument, not the definition.
- On public pages, images sized, third parties off the first paint, the heading not trapped in a slider.
Run that list on the money URLs first — services, the articles that already get impressions, the knowledge pillars you would send a buyer. Do not start with a blog archive nobody searches. Quoteability follows attention. Attention follows a question you have actually answered.
What we refuse to do in the name of citations
- Write ten thin pages that each repeat one sentence with a different city name.
- Hide the answer below a brand video or a form.
- Mark up a FAQ that is not on the page.
- Chase every new overview layout with a redesign while the H1 is still vague.
- Turn the knowledge hub into a blog, or the blog into a second knowledge hub.
Those refusals keep the site coherent. A citation you did not earn — schema that lies, a paragraph stuffed for a keyword — is worse than no citation. The person who clicks through will leave. The next crawl will notice the page does not match the lift. You will have trained both audiences to distrust the domain.
Where this sits on lavistech.com
Definitions, comparisons, and checklists live under knowledge. Monday essays live here. Public page performance, when it is a ranking problem, is explained in Core Web Vitals and done as part of web development. If you are writing your own site, use the split. If you are briefing us, send the questions the knowledge pages must answer, and the seasonal arguments you actually want dated. Do not send a keyword list and ask us to “make content”.
A page Google can quote is first a page a person can use without us in the room. Write that page. Date the claims that age. Keep knowledge and blog in their jobs. Then make the public URLs fast enough that the passage is visible on a phone. That is the whole method. It is slower than a content calendar full of synonyms. It is the only version we will put our name under when an overview lifts a sentence on a Tuesday we are not watching.
If you already have a site that ranks for the wrong question, do not add more URLs. Fix the passage on the URL that already has impressions. Change the heading to the question people ask. Put the answer first. Add the date. Remove the slogan. Wait for the field data and the snippet to catch up. New pages are for new questions. Old pages that almost answer are the cheapest citations you will ever earn — if you are willing to make them exact.