Chapter 36 — SEO and Social Sharing for Front-End

Section 1 — What search engines see

When a search engine visits your page, it does not admire your design the way a human visitor does. It reads the underlying HTML, follows links, and tries to work out what the page is about, which parts are most important, and whether the page is worth showing to someone searching for that topic. A page that hides its real content inside images, or that only reveals its text after complicated scripts run, can therefore be hard for a search engine to understand, even if it looks perfect in a browser. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs.

First the search engine discovers the page, usually by following a link or reading a sitemap. Then it reads and stores the page, a step called indexing, and later it ranks that stored page against other pages when a person searches. Ranking depends on many signals, including relevance, quality, speed, mobile usability and links from other sites, and no single trick controls it. Your job as a front-end developer is to make the first two steps easy and honest, so the page can be found and understood. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour.

Imagine a simple guide page whose heading, first paragraph and links are all plain HTML. A search engine can read the heading, understand the topic, and follow the links without guessing.

<h1>How to prune a rose bush</h1><p>Prune in late winter, cutting dead wood first.</p><a href="/guides/tools">Tools you need</a>

Keep examples short in real work too: a short, clear example is easier to test, easier to reuse and easier for a teammate to understand. The example is deliberately simple, because the idea is the point; once the idea is clear you can adapt it to longer, messier real content.

A common mistake is that the search engine sees only a blank page because the real content is loaded late by script, so put the main content in the HTML itself and treat script-loaded content as an enhancement, not as the only copy. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault.

To check your own work, open the page, view its source, and confirm the heading and first paragraph appear there without running extra steps. A good check is specific: it names what should happen, what you observed, and whether the two match. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked.

Check: Why should the main content be in the HTML itself?

Section 2 — Titles that describe the page

Every page has a title element in its head, and that title is often the first thing a person sees in search results, in a browser tab and in a bookmark list. A good title names the page's topic plainly, in the words a visitor would actually use, and it distinguishes this page from every other page on the site. A vague title such as Home or Page 1 tells nobody anything, while a title that is stuffed with repeated keywords looks untrustworthy and is hard to read. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Write one title per page, put the most important words near the start, and keep it short enough to display fully in most search results, which in practice means roughly a single clear phrase rather than a long sentence. Check that each page on the site has a different title, because duplicate titles make pages hard to tell apart in results and in tabs. The title should match the page's heading in meaning, even if the wording is not identical, so a visitor who clicks through does not feel misled. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

For a guide about pruning roses, a clear title names the task and the plant, rather than naming the site first or repeating the word rose many times.

<title>How to prune a rose bush | Garden Guides</title>

The example is deliberately simple, because the idea is the point; once the idea is clear you can adapt it to longer, messier real content. After you run an example, check the result the way a visitor would, not only the way a developer would, because the visitor's view is the one that counts.

A common mistake is writing the same title on every page of a site, so give each page its own title that describes that page alone, and check the tab text as you browse the site. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, list the titles of five pages on a site and check that each one names its own topic in plain words. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: What makes a page title useful in search results?

Section 3 — Meta descriptions that invite a click

A meta description is a short summary of a page, written in the head of the document, which search engines may show underneath the title in results. It does not directly decide where a page ranks, but it strongly affects whether a person chooses to click, because it is the page's chance to explain, in one or two sentences, what the visitor will find and why it is worth their time. A missing, duplicated or misleading description wastes that chance. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

Write the description as a genuine summary, not as a list of keywords and not as a promise the page does not keep. Mention the main benefit or answer, use natural language, and keep it to about two sentences so it is not cut off awkwardly in results. Each page deserves its own description, just as each page deserves its own title, because two different pages that share a description will look identical to a searcher even when their contents differ. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A rose-pruning guide might summarise when to prune, what to cut first, and what the reader will be able to do afterwards, in plain sentences.

<meta name="description" content="Learn when to prune roses, which stems to cut first, and how to shape the bush for healthy growth.">

If the example does not behave as expected, resist the urge to add more code; first check the basics, such as spelling, names and whether the file was saved. Read the example line by line and ask what each part is for, rather than memorising the whole block as one shape.

A common mistake is copying the same description onto every page, so write a fresh summary for each page, and read it as if you were deciding whether to click. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

To check your own work, read a page's description in search results, or in the page source, and check that it honestly summarises that page. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: What is a meta description for?

Section 4 — Semantic HTML for search

Semantic HTML means choosing elements for what content actually is, rather than wrapping everything in generic containers. A navigation element says this is navigation, an article element says this is a self-contained piece of writing, a heading says this is a heading, and a list says this is a list. Search engines, screen readers and other tools all use that meaning to understand a page's structure, so semantic markup helps both people and machines make sense of your work. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Start with the page outline: one main landmark for the main content, navigation for the site's menus, a header for introductory material and a footer for closing material. Inside the main content, use article or section elements for distinct blocks, headings in order, and real lists for lists. Avoid using a heading only to make text bigger, and avoid using a division for everything, because both habits throw away meaning that tools rely on. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

A blog post marked up as an article, with its heading, paragraphs and list of steps inside it, is far clearer than the same words wrapped in unnamed containers.

<article><h2>Pruning steps</h2><ol><li>Remove dead wood.</li><li>Cut crossing stems.</li></ol></article>

After you run an example, check the result the way a visitor would, not only the way a developer would, because the visitor's view is the one that counts. If the example does not behave as expected, resist the urge to add more code; first check the basics, such as spelling, names and whether the file was saved.

A common mistake is using generic containers for everything and styling them to look like headings or lists, so choose the element that matches the meaning, and use CSS only for how it looks. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, inspect a page and check that its headings, lists and landmarks match the meaning of the content, not just its appearance. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: Why does semantic HTML help search engines?

Section 5 — Heading structure as an outline

Headings form the outline of a page, in the same way chapter headings form the outline of a book. The level-one heading names the page's main topic, level-two headings name its major sections, and level-three headings name subsections within those. When the outline is clean, a reader can scan it and grasp the page at a glance, and a search engine can see how topics relate to each other instead of seeing a flat pile of equally important text. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for.

Use one level-one heading per page, then step down one level at a time without skipping, for example from a level-two heading to a level-three heading, never straight to level four. Write headings that describe what follows, using words a searcher might use, rather than clever phrases that hide the topic. If you want a heading to look smaller or larger, change it with CSS; never choose a level for its default size, because size is presentation and level is meaning. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug.

A pruning guide might use one main heading for the whole guide, a second-level heading for timing, another for tools, and third-level headings for individual steps inside the tools section.

<h1>How to prune a rose bush</h1><h2>When to prune</h2><h2>Tools</h2><h3>Choosing secateurs</h3>

Read the example line by line and ask what each part is for, rather than memorising the whole block as one shape. Try changing one small thing in the example, such as the text or a value, and watch what changes in the result; that experiment teaches more than reading alone.

A common mistake is skipping heading levels or using several level-one headings on one page, so outline the page on paper first, then mark it up in order, and read the headings alone to see if they make sense. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form.

To check your own work, read only the headings of a page, in order, and check that they form a sensible outline of the topic. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure.

Check: How should heading levels be used?

Section 6 — Clean, readable URLs

A URL is part of a page's public face: people copy it, share it, bookmark it and judge it. A clean URL uses plain words, separated by hyphens, that describe the page, such as a guide path naming the topic. A messy URL full of numbers, meaningless codes and long query strings is harder to share, harder to remember and harder to trust, even when the page behind it is excellent. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later.

Keep URLs short, lowercase and stable, because a URL that changes breaks bookmarks, links and search results that point to the old address. Use words that match the page's topic, avoid unnecessary parameters for ordinary pages, and do not include dates or version numbers unless the page genuinely needs them. When a page must move, redirect the old address to the new one, which is covered in a later section, rather than leaving the old address to fail. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later.

A guide about pruning roses is easier to share and to understand at a path that names the topic plainly than at a path made of codes.

/guides/prune-rose-bush

Try changing one small thing in the example, such as the text or a value, and watch what changes in the result; that experiment teaches more than reading alone. Keep examples short in real work too: a short, clear example is easier to test, easier to reuse and easier for a teammate to understand.

A common mistake is creating URLs with random numbers, underscores and capital letters mixed together, so use short lowercase words separated by hyphens, and keep the same address once a page is published. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects.

To check your own work, look at a site's URLs and check that each one can be understood, and shared, without opening the page first. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure. A good check is specific: it names what should happen, what you observed, and whether the two match.

Check: Why does a readable URL help?

Section 7 — Canonical URLs and duplicates

Sometimes the same content can be reached at more than one address, for example with and without a trailing slash, with a tracking parameter, or through a printed version of a page. To a visitor those addresses look like the same page, but to a search engine they can look like several competing pages, which splits attention and can weaken how the content is understood. A canonical link tells search engines which address is the preferred, official version. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

Add one canonical link to the head of each page, pointing to the single address you want search engines to treat as the original. The canonical address should be complete, use the secure form of the address, and match the address you actually link to elsewhere. Canonical tags are a strong hint, not an absolute command, so they work best when the pages really are near-duplicates and when your internal links already point to the preferred address. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A guide that can be reached with a tracking parameter still declares its clean address as canonical, so search engines consolidate their understanding around one version.

<link rel="canonical" href="https://example.com/guides/prune-rose-bush">

A common mistake is pointing a canonical link at a different page, or at an address that redirects elsewhere, so check that the canonical address loads the page itself, matches your links, and is used consistently across the site. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

For canonical URLs, prefer a simple, honest implementation over a clever one, because simple implementations are easier to test and easier to maintain.

To check your own work, pick a page with more than one reachable address and confirm its canonical link points to the single preferred address. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: What problem does a canonical link solve?

Section 8 — Sitemaps for discovery

A sitemap is a file, usually in XML format, that lists the important pages of a site so search engines can discover them more reliably. It is especially helpful for large sites, for new sites with few links pointing to them, and for pages that are buried several clicks deep, because it gives search engines a direct list rather than relying entirely on following links from page to page. A sitemap does not guarantee ranking, but it improves the chance that pages are found and considered. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

List the pages you want found, with their full addresses, and keep the list current as pages are added, moved or removed. Do not list pages you do not want indexed, such as private or duplicate pages, and do not list addresses that return errors. Place the sitemap at a standard location and mention it in the robots file, which is the next section's topic, and submit it through the search engine's webmaster tools where available. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A small site's sitemap might list its home page, its guide index and each guide, each with its full address, and nothing else.

<url><loc>https://example.com/guides/prune-rose-bush</loc></url>

A common mistake is listing deleted, private or broken pages in a sitemap, so keep the sitemap to live, public pages you want found, and check each listed address actually loads. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

For sitemaps, prefer a simple, honest implementation over a clever one, because simple implementations are easier to test and easier to maintain.

To check your own work, open a site's sitemap and check that every listed address loads a real, public page you would want found. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: What is a sitemap for?

Section 9 — Robots files and crawling

A robots file, named robots.txt, sits at the root of a site and gives polite instructions to search engine crawlers about which parts of the site they may visit. It is a request, not a lock: well-behaved crawlers respect it, but it does not hide content from anyone who already knows the address, and it must never be used as the only protection for private material. Used correctly, it helps crawlers spend their time on the pages that matter instead of on admin pages, search results or duplicate views. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Write the file plainly, naming the crawler or all crawlers, then the paths to disallow, and include the sitemap address. Keep it short and specific, test it after any change, and never disallow the whole site by accident, which is a surprisingly common and costly mistake. Remember that a disallowed page can still appear in results in some cases if other sites link to it, so for truly private content, use proper access control instead. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

A site might allow all crawlers on its public guides while asking them not to crawl its internal search pages or its admin area.

User-agent: *
Disallow: /admin/
Disallow: /search/
Sitemap: https://example.com/sitemap.xml

A common mistake is blocking the whole site with a single careless rule, or relying on robots rules to protect private pages, so test the file carefully, disallow only what you mean to, and protect private content with real access control. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, read a site's robots file and check that it blocks only non-public areas and still allows the important public pages. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: What does a robots file actually do?

Section 10 — Open Graph basics

When someone shares a link on a social platform, the platform does not guess what to show: it reads special meta tags in the page's head, known as Open Graph tags, and uses them to build the preview card with a title, a description and an image. Without those tags, the platform falls back to whatever it can find, which may be an unhelpful title, a fragment of navigation text or the wrong image. With them, you control the first impression your page makes in a feed. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

The four essential Open Graph tags name the type of content, the title, the description and the page's full address. Each page should have its own values, just as each page has its own title and description for search, because a shared preview that describes the home page will mislead anyone who clicks through to a specific article. Use absolute addresses, meaning the full address including the site name, because a relative address may not resolve when the preview is built elsewhere. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A shared guide should preview with its own title, its own short description and the guide's full address, not with generic site-wide text.

<meta property="og:title" content="How to prune a rose bush"><meta property="og:type" content="article"><meta property="og:url" content="https://example.com/guides/prune-rose-bush">

A common mistake is leaving every page with the same Open Graph title and description, so set page-specific Open Graph values on each page, and test a shared link before publishing widely. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, share a test link privately and check that the preview shows the right title, description and address for that page. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: What do Open Graph tags control?

Section 11 — Open Graph images

Of all the parts of a social preview, the image is usually what catches the eye first, and a missing, tiny or badly cropped image can make an otherwise good page look unfinished in a feed. The Open Graph image tag points to a single image that represents the page, and platforms crop it to their own card shapes, so the image must still read clearly after cropping. A strong share image is simple, relevant and readable at small sizes, not a dense collage of tiny text. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Choose an image that is wide rather than tall, large enough to look sharp on high-resolution screens, and hosted at a stable, public, absolute address. Avoid text that sits near the edges, because cropping may cut it off, and avoid images that only make sense with a caption, because the caption may not travel with the card. Use the same image logic for every page, but give each important page its own image where the topic differs, rather than reusing one generic picture everywhere. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

A pruning guide might use a clear photograph of secateurs and a rose stem, with no small text at the edges, as its share image.

<meta property="og:image" content="https://example.com/images/prune-roses.jpg">

A common mistake is using a tiny, portrait or edge-cropped image that becomes unreadable in a wide card, so choose a wide, clear, public image, keep important content away from the edges, and preview it before sharing. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, preview a page's share card and check that its image is clear, relevant and not badly cropped. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: Why does the share image matter so much?

Section 12 — Social cards for X

Alongside Open Graph, many platforms read their own card tags, and the most widely known set is the one used by X, formerly Twitter, which is often called a Twitter card. In practice, Open Graph tags already cover most of the preview, and the X-specific tags mainly choose the card size and, optionally, a site handle. The important point is not to memorise every platform's tags, but to understand that each platform builds its preview from tags you provide, and that missing tags mean a weaker, guessed preview. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later.

Set the card type to a large-image summary for pages with a good wide image, because that format gives the image room to be seen, and set the title and description to match the Open Graph values so previews agree across platforms. Keep the values consistent with the page itself: a card that promises one thing and delivers another will earn clicks once and distrust afterwards. Test the card with the platform's preview tool before a major launch, since a cached old preview can linger after you fix the tags. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later.

A guide with a strong wide photograph benefits from the large-image card, which shows the picture prominently above the title and description.

<meta name="twitter:card" content="summary_large_image"><meta name="twitter:title" content="How to prune a rose bush">

A common mistake is setting different titles on different platforms so previews contradict each other, so keep card titles and descriptions consistent with the page and with the Open Graph values. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects.

To check your own work, check a page's card tags and confirm the card type, title and image agree with the page itself. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure. A good check is specific: it names what should happen, what you observed, and whether the two match.

Check: What is a social card?

Section 13 — Structured data in plain words

Structured data is extra, machine-readable information added to a page that describes what the page is about in a standard vocabulary, such as saying this page is an article, this is its author, and this is when it was published. Human visitors do not see it directly, but search engines can use it to understand the page more precisely and, in some cases, to show richer results, such as extra details beneath a listing. It is not magic and it does not guarantee a richer result, but it removes ambiguity about the page's meaning. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

The most common format is JSON-LD, a small block of structured text placed in the head of the page, which keeps the machine-readable data separate from the visible content. Use only types that genuinely fit the page, fill in fields you actually know, and make sure the structured data matches what visitors see; describing a page as something it is not, or claiming details the page does not contain, is misleading and can cause the extra details to be ignored. Start with one type per page, such as an article, and add more only when they are genuinely relevant. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

An article page can declare itself as an article, with its headline, author name and publication date, in a form a search engine can read without guessing.

<script type="application/ld+json">{"@type": "Article", "headline": "How to prune a rose bush"}</script>

A common mistake is adding structured data that describes content the page does not actually contain, so describe only what is truly on the page, with fields you can verify, and keep the data consistent with the visible content. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

To check your own work, read a page's structured data and check that every claim in it is also true of the visible page. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: What is structured data for?

Section 14 — JSON-LD for articles

JSON-LD for an article is a practical starting point for structured data, because most sites publish articles, guides or blog posts, and the article type has a clear set of useful fields. The headline should match the page's heading in meaning, the author should be the real author or organisation, and the date published should be the date the article first appeared, not the date you happened to add the code. These details help a search engine place the article in time, attribute it correctly and understand what it covers. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Write the block carefully, because a single misplaced comma or bracket can make the whole block unreadable to a machine, even though visitors will notice nothing. Validate the block with a structured-data testing tool before publishing, and re-validate after editing, since a small edit can break the structure. Keep the block in the head or near the top of the body, keep it to one article per page, and do not copy another article's block without changing its headline, author and dates. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

An article block names the headline, the author and the publication date, in a compact form that a search engine can parse reliably.

<script type="application/ld+json">{"@type": "Article", "headline": "How to prune a rose bush", "author": {"@type": "Person", "name": "Ada Green"}}</script>

A common mistake is copying an article block from another page without updating its headline and dates, so write each block for its own page, and validate it before publishing. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, validate an article page's structured data and check that its headline, author and date match the page. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: What should an article's structured data contain?

Section 15 — Images: alt text and filenames

Images need words around them if they are to help search and sharing, because a search engine cannot see a photograph the way a person can. Alt text describes an image for people who cannot see it, and it also gives search engines a textual clue about the image's subject. A descriptive filename works in the same direction: a file named with plain words about its subject is more informative than a camera-generated code, even though the filename alone is only a small signal. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

Write alt text that describes what the image shows and, where relevant, why it matters in context, rather than writing image of or repeating the page title. Leave alt text empty only for purely decorative images that add no information, so assistive technology can skip them cleanly. Name files with short, lowercase, hyphenated words before uploading, because renaming after publication can break links, and avoid stuffing filenames or alt text with repeated keywords, which reads badly and helps nobody. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A photograph of secateurs cutting a rose stem deserves alt text that says so plainly, and a filename that names the same subject.

<img src="prune-rose-stem.jpg" alt="Secateurs cutting a dead rose stem above a leaf joint">

A common mistake is writing alt text that is empty for informative images, or stuffed with repeated keywords, so describe the image plainly, name the file with its subject, and check the result with images turned off. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

To check your own work, turn images off in a browser, or read the alt text, and check that each informative image is still understandable. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: Why do images need alt text?

Section 16 — Image size and performance

Large images are one of the most common reasons a page feels slow, and slowness hurts both visitors and search visibility, because people leave slow pages and search engines notice poor experience. An image that is several times larger than the space it fills, or saved in an unnecessarily heavy format, wastes bandwidth on every visit, especially on mobile connections. Good front-end work therefore treats image size as part of the page's quality, not as an afterthought. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Resize images to roughly the largest size at which they will actually display, compress them sensibly, and choose a format suited to the content, such as a photograph format for photographs and a simpler format for graphics with flat colours. Provide responsive versions where a page needs very different sizes on phones and desktops, so a phone does not download a desktop-sized image. Check the page's total weight after adding images, and treat a sudden jump as a warning to resize before publishing. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A wide share photograph that displays at a modest width on the page does not need to be uploaded at the camera's full resolution.

<img src="prune-roses-800.jpg" alt="Secateurs cutting a rose stem" width="800" height="450">

A common mistake is uploading full-resolution camera images and letting the browser shrink them, so resize and compress before publishing, and check the page weight and loading time afterwards. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, check a page's image sizes against their display sizes and confirm no image is far larger than needed. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: How do large images harm a page?

Section 17 — Core Web Vitals in plain words

Core Web Vitals is a name for a small set of measurements that describe how a page feels to a visitor: how quickly its main content becomes visible, how quickly it responds to interaction, and how much its layout shifts unexpectedly while loading. These measurements matter because a page can look complete in a screenshot yet feel frustrating in use, for example when text jumps just as a reader tries to tap a link. Search engines use experience signals of this kind among many ranking signals, but the deeper reason to care is the visitor's experience itself. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for.

Improve loading by keeping pages light and prioritising the main content, improve responsiveness by avoiding long tasks that block interaction, and reduce layout shift by reserving space for images, advertisements and other late-arriving content, so the page does not jump when they appear. Measure on real devices and realistic connections, not only on a fast office computer, because that is where the difference shows. Fix the worst experience first, rather than chasing a perfect score on one measurement while another remains poor. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug.

A page that reserves space for its main image, so the text below does not jump when the image loads, already avoids one common source of frustration.

<img src="prune-roses-800.jpg" alt="Secateurs cutting a rose stem" width="800" height="450">

A common mistake is letting images and embeds load without reserved space, so content jumps under the reader's finger, so reserve space for late content, keep pages light, and test on a real phone and a slower connection. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form.

To check your own work, load a page on a phone, watch for jumping layout and slow response, and note which element caused each problem. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure.

Check: What do Core Web Vitals describe?

Section 18 — Mobile-first rendering

Most visitors now reach many sites on a phone, and search engines generally consider the mobile version of a page first when deciding what the page contains. That means a page whose mobile version hides content, shows a stripped-down article, or loads a different, thinner version can be judged on that thinner version, even if the desktop version is rich and complete. Mobile-first is therefore not a slogan about small screens; it is a warning to keep the mobile page complete and honest. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Design and build for the small screen first, then add layout for larger screens, rather than building a desktop page and squeezing it down. Keep the main content, headings, images and links the same on mobile as on desktop, unless there is a genuine reason to differ, and test the mobile version as the real page, not as an afterthought. Check that text is readable without zooming sideways, that buttons are tappable, and that nothing important is hidden behind a menu that a crawler or a visitor might miss. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A guide whose full steps, images and links appear on a phone, in the same order as on a desktop, is a genuinely mobile-first page.

<meta name="viewport" content="width=device-width, initial-scale=1">

A common mistake is hiding the main content on mobile while keeping it on desktop, so build mobile first, keep content equal across sizes, and test the mobile page as the real page. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, open a page on a phone-sized screen and check that its full content, headings and links are present and readable. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: Why does the mobile version matter for search?

Section 19 — Internal linking

Internal links are links from one page of your site to another page of the same site, and they do several jobs at once. They help visitors move naturally from one topic to a related one, they help search engines discover pages and understand how topics relate, and they spread attention across the site instead of leaving useful pages stranded with no way in. A site with almost no internal links is like a building with locked interior doors: each room may be good, but nobody can move between them. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later.

Link where a reader would genuinely benefit, using anchor text that describes the destination, such as the title of the guide being linked to, rather than vague phrases such as click here. Link from the body of a page, where the link is part of the reading, as well as from menus where appropriate, and keep the number of links reasonable so each one still means something. Fix broken internal links promptly, because a dead link frustrates visitors and wastes the crawler's time. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later.

A pruning guide that links, in its tools paragraph, to a separate guide about choosing secateurs gives the reader a natural next step.

<p>See our guide to <a href="/guides/choosing-secateurs">choosing secateurs</a> for advice on blades and grip.</p>

A common mistake is linking with vague anchor text such as click here, or leaving useful pages with no links pointing to them, so use descriptive anchor text, link from relevant body text, and check that every important page can be reached by links. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects.

To check your own work, pick an important page and trace the links that lead to it, checking that a reader could find it naturally. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure. A good check is specific: it names what should happen, what you observed, and whether the two match.

Check: What do internal links do?

Section 20 — External links and trust

External links point from your site to a different site, and they are a normal, healthy part of the web: a guide can cite a source, recommend a tool or point readers to official information. Linking out does not harm your own site when done thoughtfully, and it can increase trust, because readers can check a claim or explore further without having to search for the source themselves. The risk comes only from careless linking, such as linking to unreliable, irrelevant or broken destinations. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Choose destinations you would be comfortable recommending, link to the specific page rather than to a home page when the specific page is the useful one, and describe the destination in the anchor text so readers know where they are going. Check external links periodically, because other sites move, change or disappear, and a page full of dead outbound links looks neglected. For links that are advertisements or sponsored, mark them as such according to the relevant rules, rather than presenting a paid link as an ordinary recommendation. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A guide that cites an official gardening association's pruning advice links directly to that advice, with anchor text naming the association.

<p>The <a href="https://example.org/pruning-advice">National Gardening Association's pruning advice</a> explains the same method.</p>

A common mistake is linking to irrelevant or untrustworthy pages, or never checking outbound links after publication, so choose destinations carefully, link specifically, and re-check external links when you update a page. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, review a page's external links and check that each destination is relevant, trustworthy and still live. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: Are external links harmful to your own site?

Section 21 — Duplicate content

Duplicate content means the same, or very nearly the same, text appearing at more than one address, or repeated across many pages of a site. Search engines may then struggle to decide which version to show, and visitors may find several near-identical results instead of one clear answer. Duplication is not usually a punishment; it is a confusion problem, and the fix is to make the preferred version clear and to give each page a reason to exist on its own. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs.

Before publishing a new page, ask what it adds that no existing page already says, and if the answer is nothing, improve the existing page instead of creating a near-copy. Where near-duplicates are unavoidable, such as print views or parameter variations, use a canonical link to point to the preferred version, and make sure internal links point there too. Avoid copying large blocks of text from other sites as well, because original, useful content is both more trustworthy and more distinctive in results. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour.

Two guides that differ only in their titles, while their steps are identical, are duplicates in practice, even if their addresses differ.

<link rel="canonical" href="https://example.com/guides/prune-rose-bush">

A common mistake is publishing many near-identical pages in the hope of covering more searches, so give each page a distinct purpose, consolidate near-copies, and use canonical links where duplicates remain. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault.

To check your own work, compare two similar pages on a site and check whether each one has a distinct purpose and distinct content. A good check is specific: it names what should happen, what you observed, and whether the two match. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked.

Check: Why is duplicate content a problem?

Section 22 — Redirects: 301 and 302

When a page moves to a new address, a redirect sends visitors and search engines from the old address to the new one automatically, instead of leaving them at a dead end. The two common types differ in meaning: a permanent redirect, status 301, says the page has moved for good and the new address should replace the old one, while a temporary redirect, status 302, says the move is only for now and the old address may return. Choosing the wrong type confuses both visitors and search engines about which address to keep. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

Use a permanent redirect when a page has genuinely moved, when a site has changed its address structure, or when two duplicate pages are being consolidated into one. Use a temporary redirect only when the move really is temporary, such as during short maintenance or testing. Check redirects after setting them up by visiting the old address and confirming it lands on the intended new page, and avoid chains where one redirect points to another redirect, because each hop slows the journey and increases the chance of error. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

An old guide address that permanently redirects to the guide's new address preserves bookmarks, links and search understanding.

Old: /rose-pruning → New: /guides/prune-rose-bush (301 permanent)

A common mistake is using a temporary redirect for a permanent move, or building long chains of redirects, so choose permanent for permanent moves, temporary only for temporary ones, and test the old address after the change. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

To check your own work, visit an old address that was supposed to move and check that it lands, in one step, on the intended new page. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: When should you use a permanent redirect?

Section 23 — Helpful 404 pages

A 404 page appears when a visitor asks for an address that does not exist, perhaps because of a mistyped link, an outdated bookmark or a removed page. A bare, technical 404 page tells the visitor nothing and usually ends the visit, while a helpful 404 page explains plainly that the page could not be found, apologises briefly, and offers useful next steps, such as a search box, a link to the home page and links to popular guides. The goal is to rescue the visit, not to blame the visitor. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for.

Keep the 404 page in the site's normal design, so visitors recognise they are still on your site, and write its message in plain words without technical jargon. Offer a way forward that matches what the visitor probably wanted: a search field, popular pages and a link back to the section they came from. Do not automatically redirect every missing page to the home page, because that confuses visitors who expected a specific page and hides the fact that a link is broken. Log 404s you see often, and fix or redirect the addresses that matter. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug.

A helpful 404 page says the page could not be found, offers a search box, and links to the home page and to popular guides.

<h1>Page not found</h1><p>Sorry, that page is no longer here.</p><a href="/">Home</a> <a href="/guides">All guides</a>

A common mistake is redirecting every missing page silently to the home page, or showing a blank technical error, so build a clear, branded 404 page with search and useful links, and fix frequently requested missing addresses. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form.

To check your own work, visit a made-up address on a site and check that its 404 page explains the problem and offers a way forward. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure.

Check: What should a good 404 page do?

Section 24 — Language and hreflang

When the same content exists in more than one language, or in regional versions of the same language, search engines need to know which version to show to which audience. The hreflang mechanism does this by declaring, on each version, the language and region of that version and of its alternates, so a French-speaking visitor is more likely to see the French version and an English-speaking visitor the English one. Without it, search engines may treat translations as duplicates or show the wrong language to the wrong audience. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Add hreflang links to every version of a page, including a link back to itself, and make sure the links are reciprocal, meaning each version points to all the others. Use correct language codes, and regional codes only where the versions genuinely differ by region, not merely to list every country. Keep the content of each version truly translated or localised, rather than machine-translating a page and declaring it a separate version without checking it, because a poor translation helps nobody. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

An English guide and its French translation each declare the other as an alternate, with their own language codes, so the right version can be shown.

<link rel="alternate" hreflang="fr" href="https://example.com/fr/guides/tailler-rosiers">

A common mistake is declaring language versions that do not actually exist, or linking only one way, so declare every version on every version, use correct codes, and check that each alternate address loads. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, pick a translated page and check that it declares itself and its alternates, with correct codes and live addresses. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: What is hreflang for?

Section 25 — Social share buttons and links

Share buttons let visitors send a page to their own networks, and they come in two broad forms: simple share links, which are ordinary links that open the platform's sharing page with your page's address filled in, and script-heavy widgets supplied by platforms, which can be slower, heavier and harder to control. Simple share links are often the better front-end choice, because they are light, accessible, predictable and easy to test, and they do not load third-party tracking code merely to display a button. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

Build share links as ordinary anchors with clear labels, such as Share on X or Share on Facebook, and make sure the link opens the platform's share page with the current page's address correctly encoded. Keep the buttons visible but not intrusive, place them where a reader who has finished the page can find them, and do not fake share counts, because invented numbers mislead visitors and will be noticed. Test each button by using it yourself, and confirm it shares the intended page with the intended preview. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A simple share link opens the platform's sharing page with the article's address already filled in, without loading a heavy widget.

<a href="https://example.com/share?url=https://example.com/guides/prune-rose-bush">Share this guide</a>

A common mistake is loading heavy third-party widgets on every page just to show share buttons, or inventing share counts, so prefer simple share links, label them clearly, and test each one by sharing the page yourself. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

For share buttons, prefer a simple, honest implementation over a clever one, because simple implementations are easier to test and easier to maintain.

To check your own work, use a page's share buttons and check that each one shares the correct page, with no invented counts. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: Why prefer simple share links over heavy widgets?

Section 26 — Share URL parameters

Most platforms accept a share address that includes the page address, and sometimes a short piece of text, as parameters in the link. Those parameters must be encoded correctly, because an address that contains characters such as question marks, ampersands or spaces will break if it is pasted raw into another address. Encoding replaces those special characters with safe forms, so the platform receives exactly the address and text you intended, no more and no less. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Build the share link by taking the page's full address, encoding it, and placing it in the parameter the platform expects, such as a url parameter. Test the link with a page whose address already contains a query string, because that is the case that most often breaks, and check that the shared preview still points to the intended page. Keep any pre-filled text short, honest and optional, and never pre-fill text that misrepresents the page or puts words into the sharer's mouth. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

A guide whose address includes a query string must still share as one clean link, with the whole address encoded as a single parameter value.

<a href="https://example.com/share?url=https%3A%2F%2Fexample.com%2Fguides%2Fprune-rose-bush">Share</a>

A common mistake is pasting an unencoded address into a share link so special characters break it, so encode the page address as a parameter value, and test with addresses that contain query strings. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, build a share link for a page with a query string in its address and check that sharing it still points to the right page. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: Why must share parameters be encoded?

Section 27 — Preview debugging tools

Platforms keep a cached copy of a page's preview, which means fixing a title, description or image may not change the preview immediately. Preview debugging tools, provided by the platforms themselves, let you enter a page address, see what the platform currently reads from it, and ask the platform to fetch a fresh copy. Using them is the difference between guessing why a preview looks wrong and seeing exactly which tags the platform found. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

Enter the page address in the tool, read the list of tags it reports, and compare each one with what you intended: title, description, image and address. If a tag is missing, check the page source, because the tool can only report what the page actually sends. If a tag is present but the preview is old, use the tool's refresh or re-scrape option, then test again, and allow a short time for the update to spread. Keep a note of which tool belongs to which platform, because each platform caches separately. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A guide whose image was changed but whose old preview still shows the previous picture can be refreshed through the platform's debugging tool, which then fetches the new image.

<meta property="og:image" content="https://example.com/images/prune-roses-new.jpg">

A common mistake is editing tags repeatedly without ever checking what the platform actually reads, so use the platform's debugging tool, compare its report with your intent, and refresh the cache after a fix. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

For preview debugging tools, prefer a simple, honest implementation over a clever one, because simple implementations are easier to test and easier to maintain.

To check your own work, use a platform's preview tool on a page and check that the tags it reports match the page's intended preview. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: What is a preview debugging tool for?

Section 28 — Content quality and search intent

Search intent means what a person actually wants when they type a query: they may want to learn how to do something, to buy something, to find a specific site, or to compare options. A page that matches that intent, by giving the answer or the help the searcher needs, is far more useful than a page that merely contains the search words. Front-end work cannot fix weak content, but it can present good content clearly, so its usefulness is obvious at a glance. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Before building a page, state its intent in one sentence: what will a visitor be able to do, know or decide after reading it. Then shape the page around that sentence: put the answer or the main steps near the top, use headings that follow the reader's questions in order, and remove filler that delays the useful part. Check the page against its intent sentence after building it, and if a section does not serve that sentence, cut it or move it elsewhere. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A how-to guide whose intent is to teach pruning should open with when and how to prune, not with a long history of roses that delays the steps.

<h1>How to prune a rose bush</h1><p>Prune in late winter, cutting dead wood first.</p>

A common mistake is writing pages around keywords while ignoring what the searcher actually wants to do, so state the page's intent in one sentence, put the useful answer near the top, and cut what does not serve it. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, state a page's intent in one sentence, then check that its opening and headings serve that intent directly. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: What is search intent?

Section 29 — Using keywords honestly

Keywords are simply the words and phrases people use when searching, and using them well means writing about a topic in the words your readers would naturally use. That is a matter of clarity, not of trickery: a guide about pruning roses should say pruning roses, because that is what the reader calls it. Keyword stuffing, by contrast, repeats the same phrase unnaturally, in headings, paragraphs and alt text, until the page reads like a list written for a machine rather than a guide written for a person. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Use the main topic phrase in the title, the main heading and the opening paragraph, where it belongs naturally, and use related, ordinary words elsewhere, such as tools, stems, seasons and growth. Write first for a human reader, then re-read and check that the topic is named clearly, rather than counting repetitions. If a sentence sounds awkward when read aloud, it is probably forced, and a simpler, natural sentence will serve both readers and search engines better. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

A natural opening names the task once, then explains it in ordinary words, rather than repeating the same phrase in every sentence.

<h1>How to prune a rose bush</h1><p>Start in late winter, when the plant is dormant and its shape is easy to see.</p>

A common mistake is repeating the same keyword phrase in every heading and sentence until the page reads unnaturally, so write naturally, name the topic clearly where it belongs, and read the page aloud to catch forced repetition. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, read a page aloud and check that its topic is named clearly but never repeated unnaturally. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: How should keywords be used?

Section 30 — Freshness and updating pages

Some pages age well and stay useful for years, while others go out of date when advice, prices, tools or links change. Updating a page is not the same as rewriting it for the sake of change: it means checking its facts, fixing broken links, improving unclear explanations and adding genuinely new information where the topic has moved on. A maintained page earns trust over time, because returning visitors find it still accurate, while a neglected page quietly loses usefulness even if it once ranked well. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for.

Review important pages on a regular cycle, starting with the ones visitors use most and the ones whose topics change fastest. When you update, change the visible content first, then check the title, description, structured data and share image still match the updated page, and note the update honestly rather than pretending the page is brand new when only a sentence changed. Keep the page's address stable across updates, so links and bookmarks continue to work. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug.

A pruning guide updated with a new note about a changed local frost date keeps its address, its title and its main steps, while the new note is clearly part of the guide.

<p>Updated note: in mild winters, check buds before pruning, as growth may start earlier.</p>

A common mistake is changing a page's date or title to look new without actually improving its content, so update facts, links and explanations first, keep the address stable, and describe updates honestly. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form.

To check your own work, pick an older page, check its facts and links, and list exactly what needs updating before changing anything. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure.

Check: When should a page be updated?

Section 31 — Accessibility helps search

Accessibility and search optimisation overlap more than many developers realise, because both depend on a page that is clear, structured and readable by tools as well as by people. Real headings, descriptive links, alt text for images, sufficient colour contrast and readable text sizes all help screen readers, and they also help search engines understand the page, because both rely on the page's underlying meaning rather than on its visual appearance alone. Building accessibly is therefore not a separate chore added to search work; it is part of the same work. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for.

Build with semantic elements, keep a logical heading order, write link text that describes its destination, and give informative images meaningful alt text, as covered in earlier sections. Test with a keyboard alone, to confirm every interactive element can be reached and used without a mouse, and test with text zoomed larger, to confirm content does not break or overlap. Fix the problems you find, because a page that is hard for some visitors to use is also harder for tools to understand and to recommend. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug.

A guide with real headings, descriptive links and alt text can be navigated by a screen reader user and understood by a search engine in the same structured way.

<a href="/guides/choosing-secateurs">Choosing secateurs: blades and grip</a>

A common mistake is treating accessibility as decoration, or adding it only after a page is finished, so build semantic, keyboard-usable, readable pages from the start, and test them that way. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form.

To check your own work, navigate a page by keyboard and by headings alone, and check that its structure still makes sense. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure.

Check: How does accessibility help search?

Section 32 — Performance budgets

A performance budget is a set of limits a team agrees in advance for a page, such as a maximum total weight, a maximum number of requests, or a maximum time to show the main content on a typical phone. Budgets turn performance from a vague wish into a checkable rule: a new image, script or widget that pushes the page over budget must be justified, reduced or rejected, rather than quietly making every page slower. Without a budget, pages tend to grow heavier with each addition until slowness becomes normal. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for.

Set a budget that fits your audience, starting with total page weight and the size of the largest images and scripts, and measure against it on a real phone and a realistic connection. Check the budget whenever a page changes, especially when adding images, embeds or third-party code, and treat a breach as a task to fix, not as a number to ignore. Keep the budget visible to the team, so decisions about new features include their performance cost from the start. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug.

A team that agrees a page should stay under a modest total weight will resize a new photograph before publishing, rather than discovering the page is slow afterwards.

Budget example: total page weight under 1 megabyte on the home page (team rule, not a universal law)

A common mistake is adding images, scripts and widgets without ever measuring the page, until it becomes slow, so agree a weight and request budget, measure on a phone, and check every major change against it. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form.

To check your own work, measure a page's weight and requests on a phone, and compare the result with a budget you write down in advance. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure.

Check: What is a performance budget?

Section 33 — Lazy loading images

Lazy loading means delaying the loading of images that are not yet visible, such as images far down a long page, until the visitor scrolls near them. The benefit is straightforward: the page loads faster at first, because the browser does not download every image at once, and visitors on slow connections or with limited data only download the images they actually scroll to. It is a sensible default for long pages, but it must be applied thoughtfully, because images that are visible immediately should never be delayed. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs.

Mark below-the-fold images for lazy loading, and leave the main image at the top of the page loading normally, so the first view is complete without waiting. Always give lazy images width and height, or otherwise reserve their space, so the page does not jump when they finally load. Test by scrolling slowly and watching images appear smoothly, and check that images still load when JavaScript is limited, since the browser's built-in lazy loading does not depend on your scripts. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour.

A long guide with photographs for each step can lazy-load the later steps, while its opening photograph loads immediately.

<img src="step-5.jpg" alt="Cutting a crossing stem" loading="lazy" width="800" height="450">

A common mistake is lazy-loading the main image at the top of the page, so the first view looks incomplete, so lazy-load only below-the-fold images, reserve their space, and keep the main image loading normally. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault.

To check your own work, open a long page, check that its first image loads immediately and later images load as you scroll, without layout jumps. A good check is specific: it names what should happen, what you observed, and whether the two match. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked.

Check: When should an image be lazy-loaded?

Section 34 — Crawling and indexing

Crawling and indexing are two different steps that are often confused. Crawling is when a search engine's program visits a page, follows its links and reads its content. Indexing is when that content is stored and analysed so it can be considered for search results. A page can be crawled but not indexed, for example if it is judged to be a duplicate, thin or low quality, and a page that is never crawled cannot be indexed at all, which is why discovery through links and sitemaps matters. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs.

Help crawling by keeping important pages linked from other pages, by keeping the sitemap current, and by avoiding accidental blocks in the robots file or in server settings. Help indexing by giving each page distinct, useful content, a clear title and description, and a clean structure, rather than publishing many thin pages that say almost the same thing. If a page is not appearing, check first whether it was crawled, whether it was blocked, and whether its content is distinct enough to be worth indexing, in that order. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour.

A new guide that is linked from the guide index and listed in the sitemap gives a crawler two clear paths to discover it.

<a href="/guides/prune-rose-bush">How to prune a rose bush</a>

A common mistake is assuming that publishing a page automatically means it will appear in search results, so check discovery through links and sitemaps, check for blocks, and make the page's content distinct and useful. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault.

To check your own work, trace how a new page could be discovered, and check that it is linked, listed and not blocked. A good check is specific: it names what should happen, what you observed, and whether the two match. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked.

Check: What is the difference between crawling and indexing?

Section 35 — Search Console in plain words

Search Console is a free tool provided by a search engine that shows a site owner how their site appears in that search engine's results, which queries bring visitors, which pages are indexed, and which pages have problems. It does not change rankings by itself, and it does not show everything, but it gives evidence where guessing would otherwise rule: you can see which pages are found, which are ignored, and what errors prevented a page from being understood. For a front-end developer, it is the feedback loop that turns search work from opinion into observation. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later.

After verifying ownership of a site, use the tool to submit the sitemap, check the indexing report for important pages, and read the experience reports for mobile usability and speed problems. Act on the errors that affect important pages first, fix the cause on the site, and then ask for the page to be reconsidered where the tool allows it. Check the tool regularly, but do not chase every minor warning at the expense of writing useful pages, because the tool reports issues to fix, not goals to maximise at all costs. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later.

A site owner who sees a guide listed as not indexed can check whether it was blocked, duplicated or thin, fix the cause, and request reconsideration.

Search Console report example: page indexed, page not indexed, and the reason given for each

A common mistake is checking the tool once, fixing nothing, and then wondering why results never change, so verify the site, submit the sitemap, fix important-page errors first, and re-check after fixing. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects.

To check your own work, list a site's important pages and check, in the tool, whether each one is indexed and, if not, why. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure. A good check is specific: it names what should happen, what you observed, and whether the two match.

Check: What is Search Console for?

Section 36 — Measuring without vanity metrics

Measuring search work means looking at evidence that connects to real visitors and real tasks, not at numbers that merely look impressive. A vanity metric, such as a raw count of page views, can rise while the site gets worse, for example if visitors arrive, find the page unhelpful and leave immediately. Better measures include which queries bring visitors, whether important pages are indexed, how long visitors stay and act, and whether the page's goal, such as reading a guide or starting a task, is being achieved. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Choose a small set of measures before you change anything, record them, make one change at a time, and compare after enough time has passed for a real pattern to emerge. Avoid changing many things at once, because then you cannot tell which change caused any movement. Be honest about uncertainty: search results vary, seasons affect topics, and a single week's movement is rarely proof of anything. The discipline is to measure, change one thing, and measure again, rather than to celebrate a single number. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A guide team that tracks indexed pages, search queries and completed reads, rather than raw views alone, can tell whether an update genuinely helped.

Measure: indexed pages, queries bringing visitors, and whether readers finish the guide

A common mistake is celebrating a rise in raw views while visitors leave immediately, or changing many things at once, so choose a few meaningful measures, record them before a change, change one thing, and compare honestly. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, pick a page, write down three meaningful measures for it, and check them before and after your next change. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: What is a vanity metric?

Section 37 — Social preview fallbacks

Even with perfect tags, a shared preview can fail: an image may be temporarily unavailable, a platform may not read a tag it used to read, or a page may be shared from a cached copy made before the tags were fixed. A fallback is a sensible default that keeps the preview usable when the ideal preview is unavailable, such as a site-wide default image and description that are used when a page has no specific ones. Fallbacks do not replace page-specific tags, but they prevent the worst outcome, which is a blank or misleading card. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Set a site-wide default title, description and image that describe the site honestly, and let page-specific tags override them on pages that have them. Test the fallback by sharing a page that has no specific image, and confirm the card still looks professional and still describes the site. Check the fallback periodically, because a default image that was once suitable can become outdated as the site changes, and an outdated default is worse than no default at all. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

A new, short announcement page with no specific share image still previews with the site's default image and a clear site description, rather than a blank card.

<meta property="og:image" content="https://example.com/images/site-default.jpg">

A common mistake is leaving pages with no tags at all, so their previews are blank or guessed, so set honest site-wide defaults, let page tags override them, and test a page that has no specific tags. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, share a page with no specific share image and check that its preview still looks professional and accurate. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: What is a social preview fallback?

Section 38 — Favicons and share appearance

A favicon is the small icon that represents a site in browser tabs, bookmarks and history lists, and a similar small icon often represents the site when it is saved to a phone's home screen. It is a tiny detail, but it affects recognition: a page with a clear, simple favicon is easier to find again among many open tabs, and a page with no favicon, or with a generic default, looks unfinished. The same principle applies to share appearance generally: small, consistent visual marks help people recognise your site at a glance. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Design a favicon that is simple, bold and readable at tiny sizes, using a single clear shape or letter rather than detailed artwork or small text. Provide it in the sizes browsers and devices expect, link it from the page head, and test it in tabs, bookmarks and on a phone home screen, where it will appear much smaller than in your design tool. Keep the favicon consistent with the site's other marks, so the tab icon, the share image and the site's logo all feel like the same site. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A site whose favicon is a simple green leaf is recognisable in a crowded tab bar, even at sixteen pixels wide.

<link rel="icon" href="/favicon.ico">

A common mistake is using a detailed photograph or tiny text as a favicon, which becomes a blur at tab size, so design a simple, bold mark, provide the expected sizes, and test it in real tabs and bookmarks. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, open a site in a crowded tab bar and check that its favicon is recognisable at tiny size. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: Why does a favicon matter?

Section 39 — Honest previews, no cloaking

Cloaking means showing search engines or platforms one version of a page while showing visitors a different version, in order to gain an advantage in results or in previews. It is dishonest, it breaks trust, and search engines treat it seriously, because their results are only useful if what they describe matches what a visitor actually gets. Honest previews follow a simple rule: the title, description, image and structured data you declare should match the page a visitor sees when they click through. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

Check your previews against the live page, not against a staging copy or an old version, and fix any mismatch promptly, even if the mismatch seems harmless. Be especially careful with pages that change often, such as event pages or price pages, where a preview made earlier may no longer match the current page. If a page's content has changed, update its tags and structured data at the same time, and refresh cached previews where the platform allows it, rather than leaving an outdated preview to mislead the next visitor. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A guide whose preview promises pruning steps should lead to a page that actually contains those steps, not to a different page or an advertisement.

<meta property="og:title" content="How to prune a rose bush">

A common mistake is declaring titles, images or structured data that do not match the page visitors actually see, so match every preview claim to the live page, update tags when content changes, and refresh cached previews. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

To check your own work, compare a page's preview with its live content and check that every claim in the preview is true of the page. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: What is cloaking?

Section 40 — Pagination and search

Pagination splits a long list, such as a catalogue of guides or a set of search results, across several pages, with links to move between them. For search engines, pagination creates a choice: each page in the sequence can be treated as its own page, with its own content, or the sequence can be seen as one long list chopped into pieces. The front-end choice matters, because a sequence whose pages are hard to navigate, or whose items are duplicated across pages, wastes crawling effort and confuses visitors. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later.

Give each paginated page a clear address, a title that shows which page of the sequence it is, and links to the previous and next pages as well as to the start, so visitors and crawlers can move through the sequence in order. Keep the items on each page distinct, avoid showing the same items on several pages, and make sure the first page of the sequence is the one most worth finding. Where a view-all page is genuinely useful and not too long, it can serve as a single, complete version alongside the paginated one. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later.

A guide index split across three pages shows page numbers, previous and next links, and a title that names the page of the sequence.

<a href="/guides?page=2">Next page</a>

A common mistake is duplicating the same items across paginated pages, or leaving paginated pages with no links between them, so give each page a distinct address and title, link previous and next, and keep items distinct per page. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects.

To check your own work, browse a paginated list and check that each page has a distinct title, distinct items, and previous and next links. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure. A good check is specific: it names what should happen, what you observed, and whether the two match.

Check: How should paginated pages be linked?

Section 41 — Single-page apps and search

A single-page application loads one HTML page and then updates its content with JavaScript as the visitor navigates, without a full page reload for each view. This can feel fast and smooth for visitors, but it creates a challenge for search, because a crawler that reads only the initial HTML may see a nearly empty shell instead of the article, product or guide that the JavaScript would later load. The challenge is not that single-page applications cannot be found; it is that their content must be made discoverable in a form crawlers can read. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks.

The usual solutions involve rendering the important content on the server, so the first HTML sent already contains the article or product, or pre-rendering key pages in advance, so each address has a complete HTML version. Both approaches keep the smooth application feel for visitors while giving crawlers real content to read. Whatever approach you choose, test it by viewing the page source and by checking what a crawler would see, rather than assuming that because the page looks complete in your browser, it is complete for everyone. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once.

A product page in a single-page application that is rendered on the server sends its title, description and product details in the first HTML, not only after scripts run.

<h1>Canvas gardening gloves</h1><p>Durable gloves for pruning and planting.</p>

A common mistake is assuming that content visible after scripts run is equally visible to every crawler, so render important content in the first HTML, and verify it by viewing the source. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult.

To check your own work, view the source of an application page and check whether its main content is present before scripts run. The goal of checking is confidence you can defend, not a quick glance that lets you move on. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea.

Check: Why can single-page apps be hard for search engines?

Section 42 — Rendering options in plain words

Rendering is the process of turning code and data into the HTML a visitor or a crawler receives, and where that rendering happens is a front-end architecture choice with search consequences. Server rendering builds the HTML on the server for each request, so the first response is complete. Pre-rendering builds HTML pages in advance, at build time, so they can be served quickly. Client rendering builds the page in the visitor's browser with JavaScript, which can feel flexible but sends an initially empty or thin page. Each option trades speed, freshness and complexity differently. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs.

Choose server rendering when content changes often or must be fresh for each visitor, pre-rendering when content is stable and shared by many visitors, and client rendering mainly for parts of a page that are personal or interactive after the main content is already visible. In practice, many sites mix these approaches, rendering the main content on the server or in advance, and adding interactive parts in the browser afterwards. Whatever mix you choose, state it plainly, test what the first HTML contains, and do not let an architecture choice silently hide the main content from crawlers or from visitors on slow devices. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour.

A news article that is pre-rendered at build time serves complete HTML instantly, while its comment section loads afterwards in the browser.

<h1>Pruning in late winter</h1><p>The full article text is present in the first HTML.</p>

A common mistake is choosing client rendering for the main content without checking what the first HTML contains, so match the rendering choice to how fresh and how shared the content is, and verify the first HTML. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault.

To check your own work, for a given page, state where its main content is rendered and verify it in the first HTML. A good check is specific: it names what should happen, what you observed, and whether the two match. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked.

Check: What are the main rendering options?

Section 43 — Viewport and mobile pages

The viewport meta tag tells a mobile browser how to size and scale the page, and without it, many pages render as a shrunken desktop layout that visitors must pinch and zoom to read. With the correct viewport tag, the browser lays the page out at the device's width, text reads at a sensible size, and layout adapts as intended. It is a single line in the head, but it is one of the most consequential lines for mobile experience and for mobile-first search, because it determines whether the mobile page is genuinely usable. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Include the standard viewport tag on every page, with the width set to the device width and the initial scale set to one, and do not disable user zoom, because visitors who need larger text must be able to zoom. Test the page at several phone widths, checking that text does not overflow sideways, that buttons are reachable, and that no content requires horizontal scrolling to read. If a page looks correct on a desktop but broken on a phone, check the viewport tag first, before rewriting layout code, because a missing tag mimics many layout faults. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A guide with the correct viewport tag reads comfortably on a phone, with text at a normal size and no sideways scrolling.

<meta name="viewport" content="width=device-width, initial-scale=1">

A common mistake is forgetting the viewport tag, or disabling zoom so visitors cannot enlarge text, so include the standard viewport tag on every page, allow zoom, and test at several phone widths. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, open a page on a phone-sized screen and check that text is readable without sideways scrolling or pinching. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: What does the viewport tag do?

Section 44 — Testing structured data

Structured data only helps if machines can read it, and a block that looks correct to a human eye can still be unreadable to a parser because of a small syntax error or a mismatched field. Testing tools check the block, report errors and warnings, and show how the page's structured data would be understood, which turns a guess into a checkable result. Testing should happen before publishing and again after any edit, because a later edit to the page or to the block can break what previously worked. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later.

Paste the page address, or the block itself, into a structured-data testing tool, read every error first, and fix errors before worrying about warnings, which are suggestions rather than failures. Check that the tool recognises the type you intended, that required fields are present, and that the values match the visible page. Keep a record of the test result for important pages, so a later change that breaks the block is noticed quickly rather than discovered months later when richer results disappear. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later.

A tested article block reports no errors, recognises the article type, and shows the headline and author exactly as they appear on the page.

<script type="application/ld+json">{"@type": "Article", "headline": "How to prune a rose bush"}</script>

A common mistake is publishing structured data without ever testing it, and assuming it works because the page looks fine, so test before publishing, fix errors first, and re-test after any edit to the page or the block. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects.

To check your own work, run a page's structured data through a testing tool and check that it reports no errors and matches the page. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure. A good check is specific: it names what should happen, what you observed, and whether the two match.

Check: Why test structured data?

Section 45 — Anchor text that describes

Anchor text is the clickable words of a link, and it is one of the clearest signals, to both visitors and search engines, about what the destination contains. Descriptive anchor text, such as the title of the guide being linked to, tells a reader where the link goes before they click, and it helps a search engine understand the destination's topic. Vague anchor text, such as click here or this link, tells nobody anything, and it is especially unhelpful for screen reader users, who may hear a list of links read out of context. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later.

Write anchor text that could stand alone and still make sense, naming the destination or the action it performs. Keep it concise, avoid repeating the same anchor text for different destinations, and avoid making whole sentences into links, which makes the clickable area confusing. Check links by reading them out of context: if you heard only the link text, would you know where it goes? If not, rewrite it until the answer is yes. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later.

A link whose text names the guide it points to is useful even when read alone, unlike a link that merely says click here.

<a href="/guides/choosing-secateurs">Choosing secateurs: blades and grip</a>

A common mistake is using click here, or the same vague text, for many different destinations, so write anchor text that names the destination, keep it concise, and test it out of context. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects.

To check your own work, read a page's links out of context and check that each one names its destination. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure. A good check is specific: it names what should happen, what you observed, and whether the two match.

Check: What makes good anchor text?

Section 46 — Content hierarchy and snippets

Search results sometimes show more than a title and a description: they may show a snippet, a short extract from the page that answers the searcher's question directly, or extra details drawn from structured data and headings. You cannot force a snippet, and you should not write for snippets alone, but a page with a clear hierarchy, a direct answer near the top, and well-structured sections is more likely to be understood well enough for a useful snippet to be drawn from it. The hierarchy does the work; the snippet is a possible reward, not a target to game. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer.

Structure the page so its main question is named in a heading, its direct answer follows immediately in a short paragraph, and supporting detail follows in orderly sections beneath. Use lists for steps and sets, tables for comparable facts, and headings that mirror the questions a reader would ask. Avoid burying the answer at the bottom of a long introduction, because both readers and tools prefer a page that answers first and elaborates second, and avoid formatting tricks designed only to attract a snippet, which can backfire. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system.

A guide that opens with a short, direct answer to when to prune, followed by steps in order, is easy to read and easy to summarise accurately.

<h2>When should I prune roses?</h2><p>Prune in late winter, before new growth starts.</p>

A common mistake is burying the direct answer at the bottom, or adding formatting tricks only to chase a snippet, so answer the main question near the top, structure the detail beneath it, and let any snippet follow naturally. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first.

To check your own work, pick a page's main question and check that its direct answer appears near the top, under a clear heading. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later.

Check: What is a search snippet?

Section 47 — Avoiding hidden text tricks

Hidden text tricks try to gain search advantage by putting text on a page that visitors cannot see, such as white text on a white background, text hidden behind images, or long lists of keywords placed where readers will not notice them. These tricks are dishonest, because they present one page to search engines and a different page to visitors, and search engines treat them as attempts to manipulate results. They also harm accessibility, because assistive technology may read hidden text aloud in confusing ways, or may miss it entirely. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs.

The rule is simple: if text is meant to influence search, it should also be visible and useful to a visitor, in the normal flow of the page. There are legitimate reasons to hide content temporarily, such as collapsed sections that a visitor can expand, or content that appears after an interaction, but those cases hide content from everyone until the visitor chooses to reveal it, and the hidden content is still part of the page's honest design. When in doubt, ask whether a visitor who found the text would feel tricked; if so, remove it. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour.

A page that lists its topics in a visible contents list, rather than hiding keyword lists in white text, is honest and useful to everyone.

<nav><a href="#timing">Timing</a> <a href="#tools">Tools</a></nav>

A common mistake is hiding keyword lists or extra text where visitors cannot see them, so keep search-influencing text visible and useful, and use hiding only for content visitors can reveal themselves. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault.

To check your own work, inspect a page for text that is present in the source but invisible to visitors, and check whether it has an honest purpose. A good check is specific: it names what should happen, what you observed, and whether the two match. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked.

Check: Why are hidden text tricks harmful?

Section 48 — Measuring a change honestly

When you change a page for search or sharing, you need a way to tell whether the change helped, hurt or made no difference, and that requires a baseline, a single change, and patience. Without a baseline, any later movement is just a number without context; without a single change, you cannot attribute movement to anything; and without patience, you will mistake normal variation for a result. Honest measurement is slower than celebrating a quick movement, but it is the only measurement worth acting on. The benefit is practical, not theoretical: a page that gets this right is easier to maintain, easier to test and easier to explain to another developer. Users rarely notice this when it works, which is exactly the point; they only notice it when it is missing, broken or inconsistent.

Record the measures you care about before the change, such as indexed status, queries bringing visitors, and whether readers complete the page's goal. Make one change, such as a new title or a faster image, and wait long enough for a pattern to form, considering seasons and other events that might affect the topic. Compare the new measures with the baseline, note what else changed in the meantime, and only then decide whether to keep, revert or extend the change. Share the result honestly with the team, including changes that did not help, because a failed test is still useful knowledge. Keep the responsibility clear: the front end presents and requests, and it should not pretend to decide things that belong elsewhere in the system. When something goes wrong, trace the same steps in reverse, asking at each point what you expected and what actually happened.

A team that records a guide's baseline, changes only its title, and compares after several weeks can judge the title change fairly.

Baseline: indexed, queries, completions — recorded before the change

A common mistake is changing several things at once and then claiming credit for any improvement, so record a baseline, change one thing, wait for a pattern, and compare honestly before deciding. Do not assume the tool is broken; first assume a small, ordinary error in your own code, and check the simplest explanations first. Testing early, with a small case, catches these mistakes while they are still cheap and easy to fix.

To check your own work, before your next page change, record its baseline measures and the single change you intend to make. Write down what you checked and what you found, especially when the result surprises you; that record becomes useful evidence later. The goal of checking is confidence you can defend, not a quick glance that lets you move on.

Check: How do you measure a single change fairly?

Section 49 — Sharing responsibly

Sharing a page is not only a technical act; it is a public act, and the preview you create travels to audiences you cannot see. A responsible share preview describes the page honestly, respects the people pictured or quoted in it, and does not use a misleading image or headline to earn a click that the page cannot repay. Front-end developers shape that first impression through titles, descriptions and images, so they share responsibility for how a page is presented when it leaves the site. In real projects this idea shows up again and again, in small pages and in large applications alike, so learning it well now saves repeated confusion later. It is worth learning properly rather than copying a snippet and hoping, because a copied snippet hides the choices you will need to make when the real content differs.

Before a page is shared widely, check its preview as a stranger would: does the title promise what the page delivers, does the image fairly represent the topic, and is any quoted person or photograph used with appropriate permission and context. Avoid sensational wording, avoid cropping an image in a way that changes its meaning, and avoid sharing pages that contain private or sensitive information about identifiable people. If a page is updated or corrected, update its preview too, so old shares do not continue to spread an outdated claim. Notice the order of the steps: each one depends on the one before it, and skipping a step usually creates a fault that looks mysterious later. A useful habit is to test with realistic content, not only with a perfect example, because long titles, empty lists and slow networks reveal the real behaviour.

A guide that shares with its own clear photograph and an honest title, rather than with a dramatic image unrelated to its steps, is sharing responsibly.

<meta property="og:title" content="How to prune a rose bush">

A common mistake is using a misleading headline or unrelated dramatic image to earn clicks the page cannot repay, so check previews as a stranger would, use fair images and honest titles, and update previews when content is corrected. It helps to keep a short note of mistakes you have made with this idea, since the same few mistakes tend to recur across projects. A second pair of eyes helps here: explain what you expected and what you got, and the gap between the two often points straight at the fault.

To check your own work, check a page's share preview and ask whether a stranger would feel fairly treated after clicking through. A good check is specific: it names what should happen, what you observed, and whether the two match. Repeat the check after any later change, because a change elsewhere can quietly break something that previously worked.

Check: Why does responsible sharing matter?

Section 50 — Putting it together: a launch checklist

A launch checklist turns everything in this chapter into a repeatable habit, so no page goes live with a missing title, a broken share image or a blocked crawler by accident. The checklist is not a guarantee of ranking or of viral sharing; it is a safety net that catches ordinary mistakes before visitors and search engines meet them. Teams that use a checklist consistently publish fewer broken pages, and they spend less time fixing problems that a two-minute check would have caught. That matters because the people using the page judge it by what they can see, understand and do, not by how clever the code behind it looks. It also matters for trust: when this part behaves predictably, visitors are more willing to stay, return and complete the task they came for.

Before publishing, confirm the title and description are unique and honest, the headings form an outline, the main content is in the HTML, images have alt text and sensible sizes, the Open Graph tags and image are set, the address is clean and canonical, the sitemap and robots file are correct, and the page works on a phone. After publishing, share the page privately, check its preview, check its indexing status in due course, and fix anything the checks reveal. Keep the checklist short enough to actually use, and update it when you learn a new lesson, so it grows with your experience. Work through it slowly, one step at a time, and check what changes at each step instead of trying to fix everything at once. If you can describe the flow in plain words before you write code, the code itself becomes much easier to write and to debug.

A launch checklist for a guide might fit on one page, with a tick box for title, description, headings, images, share tags, address, sitemap and mobile test.

<title>How to prune a rose bush | Garden Guides</title>

A common mistake is publishing without any checks, and discovering a broken preview or a missing title only after sharing widely, so use a short, written checklist before every launch, and check the live preview and indexing afterwards. Most mistakes with this idea come from rushing past the basics, not from the idea being unusually difficult. When you spot a mistake, fix the cause rather than covering the symptom, because a covered symptom tends to return in a different form.

To check your own work, write a launch checklist from this chapter, then use it on a real page and note anything it catches. Make checking part of finishing, not an afterthought, and do it before you move on to the next idea. If you cannot explain the result in your own words, treat that as a signal to re-read the section, not as a failure.

Check: What should a launch checklist include?

Practical task

Build a three-page mini-site (home, one guide, one about page) and apply this chapter end to end: give each page a unique, honest title and meta description, a clean readable address, a heading outline, page-specific Open Graph tags with a wide share image, alt text and sensibly sized images, internal links between the pages, a sitemap listing, and a helpful 404 page. Then share each page privately, check its preview with a platform debugging tool, fix anything that looks wrong, and write a short note on what the checks caught.

Chapter questions

Explain, in plain words, the difference between crawling and indexing, and why a page might be crawled but not indexed.
A shared link shows the wrong image. List, in order, the checks you would make to find and fix the cause.
Why should a page's main content be present in the HTML itself, rather than loaded only by script?
Write the Open Graph tags for a guide page, including its title, description, address and image, and explain what each tag does.
A site has many near-identical pages. What steps would you take, using canonical links, internal links and content changes, to reduce the confusion?