Website Visibility: Following a Bakery's Page From Launch to Search

Diagram of a web page moving from launch through crawling and indexing into search results, alongside a phone screen

Website visibility means two things: search engines can find, read and index your pages, and real people can use those pages once they arrive. Launching a site does neither on its own. Your files sit on a server and wait, and if nothing sends a crawler or a visitor their way, nothing happens.

To make this concrete, we'll follow one small bakery. It launches a stylish single-page JavaScript site, and weeks later its menu page still doesn't appear in search. At each step we'll see where the page gets lost, which concept explains it, and what fixes it.

In short
  • Being online is not the same as being found. Pages must be crawled and indexed before they can appear in search.
  • Crawlers mostly discover pages through real links, so every important page should be linked from your homepage.
  • Content that only appears after JavaScript runs may be missed. Put key text in the initial HTML.
  • Unique titles, clear headings, speed, mobile design and accessibility help both crawlers and people.
  • Submit a sitemap, then confirm indexing in Google Search Console instead of assuming it worked.
  1. 0:00Intro
  2. 0:33Online doesn't mean found
  3. 1:25How search engines find pages
  4. 2:16Give crawlers a clear path
  5. 3:07Tell search engines what it's about
  6. 3:59Headings are your page's outline
  7. 4:54When JavaScript hides your content
  8. 5:47Check what crawlers actually see
  9. 6:39Make every stage of loading fast
  10. 7:32Design for the phone first
  11. 8:28Accessible sites are easier to find
  12. 9:23Submit a sitemap, then confirm indexing
  13. 10:16The menu Google couldn't read
  14. 11:11Mistakes that keep sites invisible
  15. 12:08Visible to crawlers and people
  16. 12:42Build for crawlers and people from day one

Launch day: why being online isn't being found

The bakery's site goes live and looks great. But going live only puts files on a server. It doesn't tell search engines or visitors that anything exists. The pages simply wait for requests, and unless a link, a search result or a crawler points someone there, they keep waiting.

Think about how you find things yourself. You rarely type an exact address. You search for a question or a name, such as a bakery nearby or sourdough bread. If the bakery's pages aren't in those results, most potential customers never arrive. Search is effectively the front door.

There's a second kind of invisibility, too. A page that loads slowly on a phone, or can't be used with a screen reader, loses people even after they land. Visibility means being found and being usable.

  • Publishing a page and having people find it are separate steps.
  • Most discovery starts with a search, not a typed URL.
  • Slow, cramped or inaccessible pages lose visitors who do arrive.

How do search engines find a new page?

To understand why the bakery's menu is missing, it helps to know how search engines work. Google and others use automated programs called crawlers. A crawler discovers a URL, fetches it, renders it, and stores what it learns in an index. Only then can the page be ranked and shown to searchers.

The index is the key idea. Search results aren't pulled from the live web each time someone searches. They come from a huge catalogue that crawlers have built ahead of time. If a page drops out anywhere before the index, it doesn't just rank low. As far as search is concerned, it doesn't exist.

Crawlers find new pages mostly by following links from pages they already know, a bit like exploring a city street by street. A page with no links pointing to it is like a house on a road missing from the map.

  • Discover: the crawler finds the URL, usually through a link.
  • Fetch and render: it downloads the page and processes it.
  • Index: the content is stored, and only then can it rank.

Can crawlers reach the menu page?

The first question for the bakery is whether a crawler can even get to the menu. A good rule of thumb: starting from the homepage, a crawler should be able to reach every page you care about through ordinary links, without needing a search box or a login. The homepage links to sections, and sections link to individual pages.

How those links are built matters. Crawlers follow standard anchor tags with an href. Some modern navigation uses divs or buttons that change pages with JavaScript click handlers. A crawler may not treat those as links at all, which can leave a page effectively orphaned even though visitors can click through to it.

Also check two quiet blockers. A robots.txt file can block whole folders, and a noindex tag tells search engines to leave a page out. Both are useful during development, but they're easy to leave switched on by accident when the site launches.

  • Link every important page from your navigation with real anchor tags.
  • Look for orphan pages that nothing links to.
  • Check robots.txt and noindex settings on launch day.

Titles, descriptions and headings that explain each page

Once a crawler reaches a page, it needs to understand it. Titles and descriptions work like the label on a jar: they say what's inside before anyone opens it. On the bakery's sourdough page, the title names the product and the brand, the meta description sums up the page in one sentence, and the main heading confirms the topic.

The title is usually the clickable headline in search results. If every page just says Home or the brand name, neither searchers nor crawlers can tell the pages apart. The meta description often becomes the snippet under that headline. Search engines don't always use it, but when they do, one clear sentence about what visitors get makes a click more likely.

Headings describe the page's structure, like a textbook's table of contents. Give each page one H1 that states its topic plainly, such as Our Sourdough Bread rather than Welcome. Use H2s for sections like Ingredients or Prices, nest H3s inside them, and don't skip levels. Screen reader users often navigate by headings. Choose heading tags for meaning, and use CSS to control their size.

  • Write a unique, specific title for every page.
  • Write the description for humans, in one clear sentence.
  • One H1 per page, then H2s and H3s in logical order.
<title>Sourdough Bread | Lina's Bakery</title>
<meta name="description"
  content="Fresh sourdough, baked daily.">
<h1>Our Sourdough Bread</h1>

Why the menu came back empty: JavaScript and crawlers

Here is where the bakery's menu actually got lost. When the crawler fetched the menu URL, the server answered 200 OK, so nothing looked broken. But the HTML body was just an empty root div with zero menu items, and the title still said React App, a leftover template default. The result was a thin, unclear page.

This happens because many frameworks build the page inside the browser with JavaScript. Visitors see the finished page, but the first thing a crawler receives is the raw HTML. In a server-rendered page, the text and real links are already there. In a JavaScript-only page, the first response is a near-empty shell, and everything depends on scripts running successfully.

Google can run JavaScript, so this isn't hopeless. But rendering costs more, may happen later, and if a script errors or a request times out, the stored page might be blank. The usual fix is to send important content in the first response using server-side rendering, static generation or prerendering. The bakery prerendered its menu so the items appeared in the initial HTML.

  • A 200 OK response doesn't mean the content was readable.
  • Template defaults like a generic title often go unnoticed.
  • Most popular frameworks support prerendering or server rendering, often through configuration.

How to check what crawlers actually see

Your browser hides this problem, because it runs every script and shows the final result. To spot it, look at the raw response before any JavaScript runs. The first command below fetches the page with no browser and no scripts. The second searches that response for a word you know should be on the page. If it finds nothing, JavaScript is adding that text.

That's exactly how the bakery verified its fix: a quick curl and grep found the croissant in the raw HTML. If the command line isn't your thing, right-click and choose View Page Source. Unlike the inspector in developer tools, it shows the original HTML the server sent, close to what crawlers get first.

For the most reliable answer, use the URL Inspection tool in Google Search Console. It tells you whether a specific page is indexed and lets you view the HTML that Google rendered.

  • curl plus grep: quick check for text in the raw HTML.
  • View Page Source: the original HTML, not the script-built page.
  • URL Inspection: how Google fetched and rendered the page.
# Fetch raw HTML, before any JavaScript runs
curl -s https://example.com/menu
# Is your real text in it?
curl -s example.com/menu | grep Croissant

Making the site fast and mobile-friendly

With the menu readable, the next risk is people giving up. Loading works like a relay race: the browser runs through stages in order, and the page only feels ready when the last one finishes. First the server responds, and caching plus a content delivery network near the visitor shortens that wait. Then CSS and JavaScript, often the heaviest stage: trim unused styles, question every library, and defer extras like chat widgets.

Images are frequently the largest files. Resize them to their display size, use modern formats like WebP, and lazy-load those further down the page. Mobile matters just as much, because Google uses mobile-first indexing and mainly reads the mobile version of your page.

Add the viewport meta tag so the layout fits the screen instead of showing a shrunken desktop page. Use readable font sizes, give buttons and links enough space for a thumb, and don't hide important text on small screens. Content missing from the mobile layout may be content Google never considers.

  • Cache pages and use a CDN for a fast first response.
  • Ship less JavaScript and defer non-essential scripts.
  • Compress images and lazy-load the ones lower on the page.
  • Set the viewport and keep the same content on mobile.

Accessibility, sitemaps and confirming indexing

A crawler, like a screen reader, depends on text and structure rather than looks, so many accessibility practices also make content clearer to machines. Neither can see the bakery's photos, so alt text such as 'a sliced sourdough loaf with a crisp crust' gives both the meaning. Purely decorative images can use an empty alt attribute so screen readers skip them.

Strong contrast helps people with low vision and anyone reading in bright sunlight. Descriptive link text like 'See bread prices' helps screen reader users jumping between links and tells crawlers what the linked page is about, far better than 'click here'.

Finally, the bakery stopped waiting to be discovered. A sitemap, usually an XML file at an address like /sitemap.xml, lists the pages you want considered. Most frameworks and content systems generate it automatically. The bakery resubmitted its sitemap in Search Console, and URL Inspection later showed the menu as indexed. The page indexing report lists which pages are indexed and which aren't, often with a reason such as being blocked or marked noindex.

  • Write alt text that describes what an image shows and why it matters.
  • Use strong contrast and descriptive link text.
  • Submit a sitemap, then review the page indexing report regularly.

Common mistakes that keep websites invisible

Most problems that hide good sites are leftovers from development or defaults nobody changed, just like the bakery's React App title. Sites are often blocked from search during development with noindex or robots.txt, which is sensible, and then launch with the block still in place. Another frequent one is every page sharing the brand name as its title.

Key information trapped in images or JavaScript-only widgets is another trap, such as opening hours in a banner image or prices loaded only by a widget. Put important information in real HTML text and let images support it. The biggest mistake is assuming everything worked: open the indexing report and load your site on a real phone over mobile data.

  • Leftover noindex or robots.txt blocks from staging.
  • The same title on every page.
  • Important text inside images or JS-only widgets.
  • Never checking Search Console or a real phone.

Key takeaways

  • A page must be crawled and indexed before it can appear in search at all.
  • Link every important page from your homepage using real anchor tags, and check for accidental blocks.
  • Give each page a unique title, a helpful description and a clear heading outline.
  • Put key content in the initial HTML, then check the raw response to confirm it's there.
  • Make pages fast, mobile-friendly and accessible for both people and crawlers.
  • Submit a sitemap and confirm indexing in Search Console instead of assuming.

Frequently asked questions

Why isn't my website showing up on Google?

Common causes are that the page hasn't been crawled or indexed yet, nothing links to it, or a leftover noindex tag or robots.txt rule is blocking it. Content that only appears after JavaScript runs can also leave the indexed page thin or empty. The page indexing report and URL Inspection tool in Google Search Console usually show which of these applies.

Can Google read JavaScript websites?

Google can run JavaScript, but rendering costs more and may happen later than the initial crawl. If a script errors or a request times out, the stored page might be blank. Server-side rendering, static generation or prerendering puts important content in the first HTML response so it doesn't depend on scripts.

How can I see my page the way a crawler sees it?

Fetch the page with curl and search the response with grep for a word you know is on it, or use View Page Source in your browser. Both show the original HTML before scripts run. For Google's own view, use the URL Inspection tool in Search Console.

Do I still need a sitemap if my pages are linked?

Links remain the main way crawlers find pages, but a sitemap lists every page you want considered, so fewer slip through. Most frameworks and content systems generate one automatically. Submitting it in Search Console also lets you monitor which pages are indexed.

Does accessibility help with search visibility?

Yes, in many ways. Crawlers, like screen readers, rely on text and structure rather than appearance, so alt text, a logical heading order and descriptive link text make your content clearer to both. These practices also keep visitors who would otherwise struggle and leave.

What is mobile-first indexing?

It means Google mainly reads the mobile version of your page when indexing it. If text or links are hidden on small screens, Google may never consider them. Setting the viewport, using readable text and keeping the same content on mobile all help.

Watch the full video on YouTube →

Souy Soeng

Souy Soeng

Hi there 👋, I’m Soeng Souy (StarCode Kh)
-------------------------------------------
🌱 I’m currently creating a sample Laravel and React Vue Livewire
👯 I’m looking to collaborate on open-source PHP & JavaScript projects
💬 Ask me about Laravel, MySQL, or Flutter
⚡ Fun fact: I love turning ☕️ into code!

Post a Comment

CAN FEEDBACK
Ad