Website

A functioning website can therefore have very low software costs. The cost profile changes substantially when traffic, storage, database usage, email delivery, APIs, redundancy, moderation, or paid acquisition increase.

A public website does not necessarily require paid cloud infrastructure.

The major unavoidable cash expense for many small custom websites is therefore the domain rather than the development stack itself. A developer who already owns suitable hardware can also self-host, although this transfers uptime, networking, backups and hardware failure responsibility from a hosting company to the operator.

A locally functioning application is only one part of operating a website.

A typical production path is:

Application → Server/Hosting → Domain → DNS → HTTPS/CDN → Analytics → Search indexing → Authentication → Monitoring → Monetization

Each layer can fail independently.

For example, an application may be running correctly while the public site is unavailable because DNS points to the wrong address. A site may load normally for users while Google cannot index particular pages. Google login can work in development but fail on the production domain if the OAuth configuration does not match the deployed URLs.

This makes deployment and operations materially different from simply completing the application's code.

There is no single required hosting model.

A custom domain is separate from the server that runs the website.

The domain must point users toward the correct infrastructure through DNS.

Cloudflare provides a Free application-services plan with DNS, CDN, unmetered DDoS protection and Universal SSL. Its paid Pro plan is US$20/mo when billed annually or US$25/mo when billed monthly; Business is US$200/mo annually or US$250/mo monthly.

This means a small site does not necessarily need to purchase a separate CDN or public TLS certificate.

A common configuration is:

Visitor → Cloudflare → Origin server → Application

Cloudflare can proxy public traffic while the origin server remains separately managed.

For a self-hosted service, operators can restrict direct access to the origin and allow public web traffic through the proxy, provided the configuration does not unintentionally block legitimate traffic.

Two Google services commonly used by website operators measure different things.

They are complementary rather than substitutes.

Google Analytics can measure website and application interactions across devices and platforms.

Useful website measurements include:

• users;

• sessions;

• landing pages;

• acquisition channels;

• countries;

• events;

• conversions;

• user paths.

GA4 properties are provided without charge under Google's Analytics terms.

Analytics does not tell an operator whether a page has successfully entered Google's search index. That is a Search Console function.

Google Search Console is Google's free tool for monitoring a site's presence in Google Search.

It can show:

• whether Google can access the site;

• crawl and indexing problems;

• indexed and non-indexed URLs;

• search impressions;

• clicks;

• queries;

• links;

• sitemap processing;

• individual URL inspection.

It can also request recrawling of individual URLs.

A new website can be completely functional and accessible worldwide while still having little or no Google Search visibility.

These are separate stages.

Discovered → Crawled → Indexed → Served/ranked

A page being crawled does not mean it has been indexed.

A page being indexed does not mean it will rank for a useful query.

Google states that Search works through crawling, indexing and serving results, and that not every processed page is guaranteed to enter the index.

For a page to meet Google's minimum technical eligibility, Googlebot must not be blocked, the page must return a successful HTTP 200 response, and it must contain indexable content. Meeting those conditions still does not guarantee indexing.

Google also states that crawling after a request can take from several days to several weeks.

Repeatedly requesting recrawling of the same unchanged URL does not make Google crawl it faster.

An XML sitemap provides search engines with URLs the operator considers important.

A simple entry can contain:

<url>
  <loc>https://example.com/page</loc>
  <lastmod>2026-08-23T00:00:00Z</lastmod>
</url>

Google recommends absolute URLs in sitemaps.

A single sitemap is limited to 50 MB uncompressed or 50,000 URLs. Larger sites must split the URLs into multiple sitemaps and may use a sitemap index.

For a database-backed website, the sitemap can be generated automatically from published pages instead of being manually edited.

Sitemaps are particularly useful for new sites with few external links because crawlers may otherwise have fewer paths through which to discover pages.

However, sitemap submission is only a signal. Google explicitly states that it does not guarantee crawling or indexing.

RSS and Atom feeds can also be submitted as sitemap formats, but they are not required when an XML sitemap already provides the necessary URL discovery mechanism.

robots.txt controls which parts of a site crawlers may request.

A site can allow public content while excluding administrative or editing routes.

Example:

User-agent: *
Allow: /
Disallow: /api/
Disallow: /login
Disallow: /*/edit

Sitemap: https://example.com/sitemap.xml

An incorrect rule can prevent search crawlers from accessing important content.

robots.txt and noindex also solve different problems: crawling controls whether a crawler may request content, while a noindex directive tells supported search engines not to include a page in search results.

A website that requires user accounts does not necessarily need to maintain its own password system.

Google Sign-In, based on Google Identity Services, lets users authenticate with an existing Google Account.

Google's current web setup requires an OAuth 2.0 client ID. The developer creates or selects a project in Google Cloud Console, configures OAuth branding/settings and loads the Google Identity Services client library.

Production configuration can involve:

• OAuth client ID;

• application branding;

• authorized domain;

• JavaScript origin;

• redirect URI;

• consent configuration;

• backend ID-token verification.

A typical production origin might be:

https://example.com

while an authentication framework may use a callback such as:

https://example.com/api/auth/callback/google

The exact callback depends on the application's authentication implementation.

A mismatch between the configured URI and the application's URI can prevent authentication even when the rest of the website operates normally.

Google Sign-In authenticates the Google user; it does not replace the website's own session and authorization logic. The application still decides what the authenticated user is allowed to do.

Authentication should also be distinguished from authorization to Google APIs. Google Identity Services separates signing a user into a website from requesting permission to access additional Google data.

Creating a Google Cloud project for an OAuth client does not mean the website must host its application on Google Cloud.

For example, the application may run on:

Self-hosted Linux server

while using:

Google Cloud project → OAuth configuration → Google Sign-In

The server itself can remain completely outside Google Cloud.

Likewise, Google Analytics, Google Search Console and Google Cloud have different purposes despite all being Google services.

A small custom content or community website can realistically use a stack such as:

Most of these components have a free option or are open-source. Infrastructure cost therefore does not necessarily become large before a site has substantial traffic.

The more important early cost can be development and maintenance time.

A website is a distribution mechanism rather than a single business model.

Revenue depends on what the site provides and what economic action occurs after traffic arrives.

Common models include:

Traffic alone is therefore not revenue.

Two websites with the same monthly visitors can have radically different economics depending on visitor geography, purchase intent, advertising niche, conversion rate, pricing and revenue model.

Display advertising is one of the easiest monetization models to understand operationally because revenue can begin without building a proprietary payment product.

Google AdSense is one example, but advertising economics should be evaluated using publisher-side metrics such as RPM rather than advertiser CPM.

For a content site:

Page RPM = estimated publisher revenue / page views × 1,000

A site with substantial traffic can still generate weak advertising revenue when visitors come from low-value advertising markets or when the content has little commercial intent.

Advertising also creates a trade-off between monetization and user experience because additional placements can increase visual clutter and page weight.

Affiliate monetization works best when a page sits close to a purchasing decision.

Examples include:

• product comparisons;

• software comparisons;

• hosting recommendations;

• equipment guides;

• business-service directories.

The economically important values are not raw traffic alone but:

Visitors × outbound-click rate × merchant conversion rate × commission

A smaller high-intent website can therefore be more valuable than a larger general-information site.

Actual commission rates and attribution windows should be checked against each affiliate program rather than assumed across the industry.

Subscriptions can reduce dependence on advertising but require a reason for users to pay repeatedly.

Web products commonly place payment around:

• premium tools;

• additional data;

• advanced search;

• saved workflows;

• team features;

• higher usage limits;

• removal of advertising;

• professional features.

This changes the important metric from page views toward paying conversion, churn and revenue per customer.

Wiki and user-generated-content sites have additional monetization options because contributors can continuously expand the site's searchable content.

Fandom is an example of a for-profit Wiki platform whose business includes advertising and commercial partnerships.

Other knowledge/community projects may instead use donations, memberships, subscriptions or combinations of these models.

The existence of a large Wiki does not establish that a new Wiki can reproduce its economics. Community size, search distribution, moderation cost and accumulated content are major differences.

A content-heavy website can accumulate pages that independently receive search impressions.

For example:

/wiki/topic-a
/wiki/topic-b
/wiki/topic-c
...

Each page becomes another potential search entry point.

This makes structured Wiki, directory and database models different from a small fixed marketing website: adding useful pages expands the site's searchable surface area.

However, creating URLs alone does not create search traffic. Google explicitly states that sitemap submission does not guarantee indexing, and indexing itself does not guarantee that a page will be served prominently for a query.

The first version of a website can be unusually cheap because many infrastructure components have free tiers.

Costs tend to appear as the service grows.

A basic public website should have:

• a publicly reachable host;

• a domain or provider URL;

• valid HTTPS for normal production use;

• working DNS;

• a deployment process;

• backups for data that cannot be recreated.

A website seeking Google Search traffic should additionally ensure that:

• Googlebot is not blocked;

• indexable pages return HTTP 200;

• important pages contain indexable content;

• internal links are crawlable;

• canonical URLs are intentional;

• important URLs are discoverable.

A website with accounts must additionally maintain application-level sessions, authorization and account data even when an external identity provider handles authentication.

• Google Search Central — How Google Search Works

• Google Search Central — Crawling and Indexing FAQ

• Google Search Central — Ask Google to Recrawl Your URLs

• Google Search Central — Sitemaps Overview

• Google Search Central — Build and Submit a Sitemap

• Google Search Console Help — About Search Console

• Google Analytics

• Google Analytics Terms of Service

• Google Identity Services — Overview

• Google Identity Services — Setup

• Cloudflare — Plans

• Cloudflare — Free Plan