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, payment processing, moderation, customer support, 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, security, and hardware-failure responsibility from a hosting company to the operator.

A custom domain is not technically required when a hosting provider supplies a subdomain, but it is normally part of a serious public or commercial deployment.

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.

When a CDN or reverse proxy is used, there can be two separate encrypted connections:

Visitor → CDN/proxy → Origin

A valid edge certificate therefore does not by itself guarantee that the origin TLS configuration is correct.

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

They are complementary rather than substitutes.

Other analytics products such as Plausible Analytics, Matomo, and Cloudflare Web Analytics can be relevant when privacy, data ownership, or lighter client-side scripts are priorities.

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.

For a global website, analytics should also be interpreted geographically. Conversion rates, advertising value, purchasing power, payment methods, and user behavior may differ substantially between countries.

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;

• countries;

• devices;

• 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 discovered does not mean it has been crawled.

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.

Search visibility can also differ by country and language. A page that performs well for one geographic audience may have little visibility elsewhere because competition, language, search intent, and available results differ.

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.

Other representative authentication services include Auth0, Clerk, Supabase Auth, and Firebase Authentication.

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.

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.

There is no useful global "average website income" that applies across websites because a personal blog, SaaS application, ecommerce marketplace, subscription publication, and financial comparison site generate revenue through fundamentally different transactions.

More useful economic measures depend on the model:

• advertising → publisher revenue per 1,000 pageviews or sessions;

• affiliate → commission per referred sale or action;

• subscription → paying subscribers × net revenue per subscriber;

• marketplace → transaction volume × take rate;

• SaaS → customers × recurring revenue per customer;

• sponsorship → contracted payment per placement or campaign.

These measures should not be combined into a single website-wide earnings benchmark.

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

For AdSense for Content, Google states that publishers receive 80% of revenue after the advertiser platform takes its fee. When advertisers buy display ads through Google Ads, Google says publishers retain approximately 68% of advertiser spend.^{[1][1]This is Google's revenue-share structure, not a prediction of the RPM an individual website will earn.}

The revenue-share percentage does not mean advertising earnings are geographically equal.

Actual publisher RPM can differ substantially according to:

• visitor country;

• advertiser demand;

• topic;

• season;

• device;

• traffic source;

• ad viewability;

• time on page;

• ad placement.

A site with substantial traffic can therefore generate weak advertising revenue when visitors come from lower-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.

Google's AdSense payment threshold also depends on the account's reporting currency. For accounts using U.S. dollars, the payment threshold is US$100; other currencies have their own thresholds.

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.

For example, the U.S. Amazon Associates program lists standard commission rates that vary substantially by product category, including 10% for Luxury Beauty, 4.5% for Physical Books, Kitchen and Automotive, and 3% for many Home, Pets, Sports and other categories.^{[2][2]These are U.S. Amazon Associates rates and should not be generalized to Amazon affiliate programs in other countries.}

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.

A website can process recurring payments through Stripe, a merchant-of-record service, or another payment provider appropriate to the operator's country.

Hosted publishing platforms may add another platform fee. Substack, for example, charges publishers 10% of each paid-subscription transaction in addition to payment-processing and billing fees charged through Stripe.

Payment availability, processing fees, local payment methods, taxes, and currency-conversion costs can differ by country, so one country's payment economics should not be generalized globally.

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 advertising, donations, memberships, subscriptions, sponsorships, affiliate links, paid listings, 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, accumulated content, brand recognition, and advertiser relationships 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 economic value of search traffic also depends on what visitors do after arriving. Traffic to a high-intent comparison or purchase page can have very different economics from general informational traffic.

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.

These components are often absent from a local prototype but become more important once users depend on the site.

Representative error-monitoring options include Sentry, application logs, hosting-provider monitoring, and cloud observability services.

Websites that send account verification, password recovery, login links, receipts, or notifications can use services such as Resend, Amazon SES, SendGrid, or Postmark rather than operating their own mail server.

Important dynamic data should also have a recovery plan. This may include:

• database backups;

• uploaded files;

• configuration;

• source code;

• off-server backup copies.

A backup is useful only if the data can actually be restored.

There is no universal license or registration requirement simply for putting a website online.

Actual legal and commercial requirements depend on the operator's country, customer locations, business model, data collected, payment activity, user age, industry, and content.

A basic public website should technically 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.

A commercial website may additionally need privacy disclosures, terms, tax handling, consumer disclosures, cookie or tracking consent, or other measures depending on the jurisdictions and activities involved.

Requirements from the United States, European Union, Korea, or another jurisdiction should not be assumed to apply globally.

• 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

• Google AdSense Help — AdSense revenue share

• Google AdSense Help — Payment thresholds

• Cloudflare — Plans

• Cloudflare — Free Plan

• Cloudflare Docs — Universal SSL

• Amazon Associates — U.S. Standard Commission Income Statement

• Substack Help — How much does Substack cost?

• Stripe — Pricing

• Vercel — Pricing

• Supabase — Pricing

• Sentry — Pricing

• Resend — Pricing