Publishing and Maintaining a Website

A website needs one project folder containing every file visitors will use. This is the site root. Publishing is much easier when that folder is a complete, portable site: no images borrowed from Downloads and no style sheet left in another project's folder.

Give each kind of file a place

A small repair shop could use this layout:

riverside-bikes/
  index.html
  prices.html
  contact.html
  404.html
  css/styles.css
  scripts/menu.js
  images/logo.svg
  images/workshop-800.jpg
  images/workshop-1600.jpg
  blog/index.html
  blog/winter-checklist.html

The HTML pages are the content, css/ holds styles, scripts/ holds JavaScript files, and images/ holds the images ready for visitors. A site without scripts does not need a scripts folder. Separate folders make related files easier to find without changing how a browser uses them.

Most web servers send index.html when a visitor requests a folder. The address https://www.example.com/ opens the root home page. The address https://www.example.com/blog/ opens blog/index.html. A file named home.html is still a page, but the server usually will not choose it for the bare site address.

Choose names before launch

Use lowercase letters, hyphens between words, and the correct extension. opening-hours.html and team-photo.jpg are clear names. Spaces can appear in URLs as %20, making an address harder to read and type. Names become part of the site's public addresses, so choose them for the content they identify.

The extension should match the file: .html for HTML, .css for CSS, .js for scripts, and a suitable image extension such as .jpg, .webp or .svg. The server sends a Content-Type header describing the file's format. Hosting systems commonly use extensions to choose that type. Renaming a photo from .jpg to .webp does not convert its contents; export it in the new format with an image tool.

Most servers distinguish uppercase and lowercase names. A link to Logo.svg can fail when the uploaded file is logo.svg, even if it worked on a computer with a case-insensitive file system. A lowercase naming habit keeps that difference out of new projects.

Separate public files from working files

Keep camera originals, design files and notes outside the site root, for example in riverside-bikes-originals/. Export only the prepared web images into images/. Files in the published folder can be downloaded even when no page links to them. Keep passwords, private documents and personal data out of that folder.

Before upload, check that every linked local asset is inside the project. A photo at a personal file:// address exists on your computer; it does not travel with the site unless you copy it into the published folder. After moving it, update the link and test it again.

A stable structure also protects links after launch. Moving prices.html to a new address breaks old bookmarks unless the host redirects that old address to the new page.

A path tells the browser where to look for a file. To write one correctly, identify both the file being requested and the location from which the browser will resolve the path.

Start in the referring file's folder

A relative path begins from the current page's folder. In the bike shop site, index.html links to prices.html with href="prices.html", to the logo with src="images/logo.svg", and to a post with href="blog/winter-checklist.html".

From inside blog/winter-checklist.html, the route changes:

<link rel="stylesheet" href="../css/styles.css">
<a href="../index.html">Home</a>
<img src="../images/logo.svg" alt="Riverside Bike Repair">
<a href="autumn-tips.html">Autumn tips</a>

For the logo, first go up from blog/ with ../, then enter images/. A file in the same folder needs only its name. Two levels up use ../../. Always use forward slashes / in web paths, including when writing on Windows.

A path in a CSS file starts from the CSS file's folder. In css/styles.css, the rule background-image: url("../images/pattern.svg"); goes up from css/ and then down into images/. It does not start from whichever HTML page happens to load the style sheet.

Distinguish three address forms

An absolute URL includes the scheme and host name. Use one for another website. Relative paths let your own site move between a local server, a preview address and its final domain without replacing the domain in every link.

A leading slash has a specific meaning. At https://username.github.io/riverside-bikes/, /css/styles.css requests https://username.github.io/css/styles.css. It drops the project folder from the address. From the site's root page, css/styles.css keeps that folder and reaches the intended file.

Test the address the browser actually uses

Opening HTML directly from disk gives a file:// address. Folder links and paths beginning with / can behave differently there. Run a local development server from the site folder, for example with python3 -m http.server, or use a code editor's live preview. Then open the local HTTP address it supplies.

On a server, href="blog/" opens blog/index.html. If a link or image fails, open DevTools before reloading and find its request in Network. A 404 means the requested resource was not found. Read the full requested URL and compare each folder, slash, letter and extension with the uploaded files. A capital letter or missing ../ is enough to send the browser elsewhere. A personal computer path copied from a file explorer cannot serve visitors; replace it with a path inside the site.

Browsers try to display pages even when the code contains mistakes. That recovery is useful for visitors, but it can hide problems from the author. Validation checks HTML or CSS against the rules of its standard, independently of whether the page happens to look right.

Use the checker for the language

The W3C Nu Html Checker checks HTML. The W3C CSS Validation Service checks CSS. You can submit a published URL, upload a file or paste code. An editor's built-in checks are useful while writing; the web checkers also let you check the published copy.

Read the line and column attached to each message. An error breaks a rule and needs fixing. A warning or information message asks for attention but may describe allowed code. Read what it says before deciding whether a change is needed.

Work from the first error downward and rerun the checker after the fix. One missing quote or badly closed element can make later code appear to belong somewhere it does not, producing many follow-on messages.

Repair structure in HTML

Consider incorrectly nested elements:

<p>Open <strong>daily</p></strong>

The inner <strong> must close before the outer <p>:

<p>Open <strong>daily</strong></p>

For a meaningful photo, supply an alt attribute describing its relevant content, such as alt="Mechanic adjusting the brakes of a city bike". A decorative image uses an empty alt="". Each id must also be unique within its page. Use a shared class when several elements need the same style.

Other useful checks include the doctype, a page title, complete attribute quotes and list items inside a list. A <div> cannot sit inside a paragraph. The browser closes that paragraph before the division, and a later </p> can become a stray closing tag. The corrected browser structure can differ from the text you wrote.

Repair declarations in CSS

A number and its CSS unit belong together: write width: 100px;, with no space between 100 and px. The property for text color is color. An unknown property is ignored.

A missing semicolon can damage the next declaration too:

.card {
  margin: 10px
  padding: 5px;
}

The browser reads the two lines as one invalid declaration. Add the missing semicolon after 10px, then check again. Browsers usually skip invalid declarations without displaying an on-page error.

Combine code checks with page checks

Passing validation does not establish that the page is accessible, fast, useful or factually correct. Try keyboard navigation, examine the layout in browsers and check the content itself. If the CSS checker flags a very new feature, check its specification and MDN support information before removing working code; checkers can lag behind newer features.

Validate after substantial changes and before publishing. After upload, submit the live address and verify that the latest content is visible. A valid older page can pass just as easily as the updated one.

Developer tools, often called DevTools, show how the browser interprets your page. Right-click an item and choose Inspect. You can also use F12 or Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on macOS. In Safari, first enable "Show features for web developers" in Settings, Advanced.

Inspect the browser's structure

The Elements panel, called Inspector in Firefox, shows the DOM: the structure built from the HTML. The browser may have repaired invalid markup, so this is not always a direct copy of the source. A <div> written inside a paragraph appears outside it in the DOM because the browser ends the paragraph first.

Select the item with the problem. The Styles pane lists matching CSS rules and links to their source files and line numbers. A crossed-out declaration is not active. Another rule may beat it, or a warning icon may show that the declaration is invalid. The Computed pane shows the final property values after the browser has resolved those rules.

Follow a losing color rule

Suppose this link appears navy even though its button class asks for white:

<a class="btn" href="contact.html">Contact us</a>

#main a { color: navy; }
.btn { color: white; }

Both rules match when the link is inside id="main". The id selector makes #main a more specific: its specificity is (1, 0, 1), compared with (0, 1, 0) for .btn. In these ordinary rules, putting .btn later does not overcome that difference.

One targeted fix is #main .btn, with specificity (1, 1, 0). Another is replacing the broad id rule with a link class such as .nav-link. Two single-class selectors have equal specificity, so their order can decide the color. Changing #main a to .main a still leaves (0, 1, 1), which beats .btn. Inspect the actual winner before choosing the smallest useful correction.

Measure the whole box

The box model diagram separates content, padding, border and margin. With box-sizing: content-box, a 300px content width plus 20px padding on each side and 2px borders takes:

That is a 344px border box, before any margins. With box-sizing: border-box, the whole border box stays 300px wide; its content width becomes:

Use the diagram to explain a gap or overflow instead of repeatedly changing widths by guesswork. Flexbox and grid badges can also show layout tracks, lines and gaps.

Try a change, then save it

Toggle a declaration off, edit a value or add a rule in Styles. Force :hover or :focus to examine a state without keeping the pointer or keyboard in place. These edits are temporary: ordinary DevTools editing does not update your project files. Copy the working change into the source, save and reload. If the fix disappears, it has not yet been saved in the copy the browser loads.

A page is assembled from several requests. The HTML can arrive successfully while a style sheet or image fails. Console messages and the Network panel show these separate outcomes.

Open the tools before reloading

The Console reports errors and warnings, including script failures, missing resources and mixed content. Messages often link to the affected file and line. Even an HTML-and-CSS site can have useful Console messages.

The Network panel records the page's requests while DevTools is open. Open it, reload, then filter by CSS, images or fonts to reduce the list. Read the requested URL, status, type, size and time. Select an entry to inspect its response headers and contents.

A status in the 400s concerns the request; one in the 500s concerns the server. A 404 is not evidence that you need to change the CSS layout.

Trace a missing logo

The live page has an empty image space. In Network, its request is https://www.example.com/images/Logo.svg, returning 404. The uploaded file is images/logo.svg. The requested capital L does not match the actual lowercase name. Correct the HTML path, deploy the page, and confirm the request now succeeds.

Trace an unstyled page

Look for the CSS request first. If no request appears, inspect the <link> element, including rel="stylesheet". If the request is 404, compare its URL with the uploaded location.

A 200 is only a successful response, not confirmation that the response is CSS. Check the Console and the response's Content-Type, which should be text/css. A host can mistakenly return an HTML error page with 200 status, and the browser will refuse to apply it as a style sheet. Once the correct CSS has arrived with the right type, inspect invalid declarations and selectors that do not match the affected element.

Rule out the browser's saved copy

A cache stores files for reuse. It saves download time, but an old copy can make a successful update look missing. With DevTools open, enable "Disable cache" in Network and reload. In Chrome, Edge and Firefox, Ctrl+Shift+R on Windows and Linux or Cmd+Shift+R on macOS forces a full reload. Inspect the returned content before concluding that the upload failed.

The size and timing columns also help with speed problems. A 3.6 MB image among tiny text files is a useful starting point. Network throttling simulates a slower connection. An HTTPS page that requests a file with http:// can trigger a mixed-content warning; inspect the exact resource URL to find the insecure reference.

A useful bug report describes an observable difference: "At 360px wide, the contact page scrolls sideways." That is easier to investigate than "the mobile layout is broken." Record the page address, browser, screen width, actual result and expected result.

Follow evidence through five steps

1. Reproduce. Make the problem happen again in the same conditions.
2. Gather evidence. Read Console and Network, validate the code, and inspect the affected element.
3. Isolate. Disable one rule or temporarily remove a small piece of code to narrow the cause.
4. Change one thing. Test whether that change explains the result.
5. Save and retest. Put the fix in the source, reload and check other conditions.

Changing several things at once makes the result hard to interpret. One change may solve the original issue while another creates a new one. Keep the failing case available so you can compare before and after.

Work through a narrow-screen overflow

A page fits on a laptop but scrolls sideways at a 360px viewport. Open responsive mode at that width. Hover over elements in Elements and watch their highlighted boxes. An image is wider than its column; its HTML gives a large intrinsic width, and no CSS limits it.

Try this rule:

img {
  max-width: 100%;
  height: auto;
}

The maximum width lets the image shrink to its container. Automatic height preserves its proportions. If the overflow disappears, save that rule in the correct style sheet and reload. Then test the image at wider widths too. Hiding horizontal overflow on the page could conceal part of the image without making it fit.

If the change does nothing, use the evidence to narrow the next step. Does the rule appear in Styles? Is it overridden? Did the browser load the file you edited? Common causes include mismatched class names, incorrect paths, missing braces or semicolons, unsaved files and cached copies.

Test engines as well as window sizes

Responsive mode changes viewport width and can simulate touch, but it does not reproduce every detail of a real phone's speed, fonts or rendering. Check the media-query breakpoints and the widths between them, then use at least one real phone.

Chrome and Edge use Blink, Firefox uses Gecko, and Safari uses WebKit. Two browsers using the same engine do not provide the same breadth of testing as browsers using different engines. Safari is particularly relevant for the many iPhone browsers that use WebKit. Check MDN's support information before relying on a newer feature.

Check the published version

Server behavior can expose failures hidden on disk: case-sensitive names, missing uploads and paths that skip a project subfolder. Open the live address, follow the links and inspect failed requests there.

Before publishing, validate the HTML and CSS, inspect Console errors, check for unintended 404s, try phone, tablet and desktop widths, and check at least two browser engines. Use the keyboard to follow navigation and activate controls. After deployment, repeat the checks on the live site where the changed feature is used.

An optimized image is a small file that still looks good at its displayed size. Start with the format, pixel dimensions and compression. Shrinking an oversized photo with CSS changes its appearance, but the browser still downloads and decodes the original file.

Match the format to the content

Raster images store pixels. Enlarging a small raster image reveals blur because no extra detail is created. SVG stores shapes and lines, so it suits a logo but not a camera photo. Current major browsers support WebP and AVIF. For animation, a modern image format or short video often makes a smaller file than GIF.

Lossless compression preserves pixel values. Lossy compression removes some detail to save more bytes. Lower quality eventually produces blocky areas or blurred edges. Compare the export at its actual displayed size. Make each new export from the original, avoiding repeated lossy saves of an already compressed copy.

Resize for the largest use

A photo displayed at most 800 CSS pixels wide needs about 800 image pixels on a standard-density screen and 1,600 on a screen using two device pixels per CSS pixel. Prepare suitable alternatives instead of sending the camera original to everyone.

The bike shop's original is 4,000 × 3,000 pixels and 3.6 MB. A 1,600 × 1,200 export has:

pixels, or 16% of the original 12 million. A JPEG export at quality 80 might be about 240 KB; the actual size depends on the photo. That example saves about 93% of the file bytes.

At 10 Mbit/s, using decimal MB, the original's ideal transfer time is:

seconds. The 0.24 MB export takes about 0.19 seconds. These are transfer times only; real loading also includes connection and server delays. Decoded at 4 bytes per pixel, memory use drops from 48 MB to 7.68 MB. A smaller encoded file and fewer decoded pixels are separate gains.

Export a public copy

Use an image editor's export controls or a tool such as Squoosh. Keep the original outside the published folder and give the exports clear names such as workshop-800.jpg and workshop-1600.jpg. Strip camera metadata during export; it can include the photo's date, camera details and GPS location.

For an SVG, an optimizer such as SVGO removes drawing-program leftovers. Text compression on the server can reduce its transfer size further. For any format, inspect the finished image: a photo saved as PNG can be unnecessarily large, while a text-heavy logo saved as JPEG can have smeared edges.

An image can be small enough to download quickly yet still make a page jump. The browser needs to know its proportions before the image arrives and needs useful choices for different screens.

Reserve space with dimensions

Write numeric width and height attributes without units:

<img src="images/workshop-800.jpg"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

These dimensions tell the browser the 4:3 aspect ratio. With max-width: 100%; height: auto; in CSS, the image shrinks to fit a narrow column. In a 360px-wide column, its height is:

pixels. Reserving that space keeps the text below from moving down when the image loads. Missing dimensions can produce layout shifts, the unexpected movements measured by CLS.

Offer widths the browser can choose

For the same photo at two sizes, use width descriptors and a description of its display width:

<img src="images/workshop-800.jpg"
     srcset="images/workshop-800.jpg 800w,
             images/workshop-1600.jpg 1600w"
     sizes="(max-width: 840px) 100vw, 800px"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

800w and 1600w state the actual file widths. In this layout, sizes says the image occupies the viewport width up to 840px and 800px above that. The browser uses the declared slot width, screen density and its selection rules to choose a file. Make sizes match the real layout; a full-viewport claim for a much narrower column can cause unnecessary downloads.

Offer formats with a fallback

<picture>
  <source srcset="images/workshop.avif" type="image/avif">
  <source srcset="images/workshop.webp" type="image/webp">
  <img src="images/workshop.jpg" width="800" height="600"
       alt="Mechanic adjusting the brakes of a city bike">
</picture>

The browser chooses the first supported source format. The required <img> supplies the fallback, dimensions and alternative text. This is a format choice; srcset with width descriptors solves the related problem of choosing a suitable pixel width.

Delay images that are not needed yet

Use loading="lazy" for images farther down a page. The browser can wait until the visitor gets near them, saving data for images never reached. Keep images visible at first load eager, especially the large main hero image. Lazy loading that image delays the content visitors are waiting to see. A hero in the HTML is discovered early; fetchpriority="high" can request higher fetch priority for it.

Write alt text for the image's purpose in context. A decorative image gets alt="". Meaningful photos and diagrams belong in HTML as images; a CSS background suits decoration and has no alt attribute or native loading attribute.

Page weight is the total data downloaded for a page. The HTML leads to requests for CSS, images, scripts and fonts. File sizes, request count, connection speed and device performance all contribute to the experience.

Find the largest share

The bike shop home page downloads 15 KB of HTML, 30 KB of CSS, two 40 KB fonts, a 2,400 KB hero and three 350 KB photos:

KB. Images account for 3,450 KB, about 96.5%. With a 220 KB hero and three 45 KB photos, the total becomes:

KB, about 87% less. At 10 Mbit/s, ideal transfer time drops from about 2.86 seconds to 0.38 seconds. Server response and connection setup add time. Removing a few spaces from CSS would have little effect beside this image saving.

Read the experience measures

The Core Web Vitals, as of October 2026, measure different problems:

Good field performance meets each threshold at the 75th percentile. CLS can include a banner shifting content after loading, not just an image arriving during initial load.

Lighthouse in Chrome or Edge runs a lab test with scores and suggested fixes. PageSpeed Insights runs online tests and, when enough observations exist, shows field data from real Chrome visits. A lab score is one test under chosen conditions. Repeat comparisons with the same settings and look at real visits when available.

Improve the biggest costs first

Prepare images and their markup first. Then reduce unnecessary font families and weights, use WOFF2 fonts, and use font-display: swap so fallback text appears while the font loads. Add defer to suitable external scripts so downloading does not block HTML parsing and execution follows parsing. Large maps, video players and other third-party embeds can be loaded on demand.

Minification removes spaces and comments from code. gzip or Brotli compression reduces transferred text bytes. These help, but already compressed JPEG, WebP and AVIF images gain little from further text-style compression.

Caching lets returning visitors reuse files, controlled through headers such as Cache-Control. A CDN keeps copies in different regions to reduce the distance requests travel. When a long-cached resource changes, a name such as styles-v2.css or address such as styles.css?v=2 makes it a new request. Test under network throttling and on a phone; a quick laptop on Wi-Fi can hide a slow mobile experience.

Each page should explain its own purpose in its HTML. Search engines read that markup, while browser tabs, bookmarks and screen readers also depend on it. Clear structure begins with the content visitors can actually read.

Name the page in the head

The <title> element belongs in <head>. Give each page its own descriptive title, with the site name after the specific topic:

<title>Repair Prices – Riverside Bike Repair</title>
<meta name="description"
      content="Prices for flat repairs, brake adjustments and full services at Riverside Bike Repair. Walk in Monday to Saturday or book online.">

The title appears in the browser tab and bookmarks and usually contributes the headline in search results. HTML does not impose a title length limit, but search displays cut text to fit, so put the useful words first. A generic title such as "Home" gives little information when separated from the site.

The meta description is a readable one- or two-sentence page summary. Search engines may use it for a result's snippet, but they can select page text instead. Match the description to that page's content. Copying one description across every page hides the differences between them; a list of repeated keywords is not a useful summary. Google ignores the old keywords meta tag.

Declare language and characters

Use <html lang="en"> for an English page. It helps screen readers choose pronunciation and browsers handle language features. Google identifies language from visible text and ignores this attribute, so do not treat it as a Google language-setting switch.

Place <meta charset="utf-8"> early in the head so characters such as é and an en dash display correctly. Include the viewport meta tag used for responsive pages:

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

Make the outline match the ideas

Use one clear <h1> for the main page topic, <h2> for its main sections and <h3> for subsections. On the prices page, "Services" is an h2, with "Basic service" and "Full service" as h3 headings beneath it. Choose heading levels for this relationship; adjust their visual sizes with CSS.

Semantic elements identify roles: <nav> for navigation, <main> for the main content, and appropriate <header>, <article>, <section> and <footer> elements. Use actual lists, links for navigation and buttons for actions. A page of generic divisions loses these role signals. Keep important words such as prices, opening hours and headings in HTML text, where they are available as text to visitors and tools.

Set a useful shared-link preview

Open Graph tags describe a link preview in social and chat apps. Common properties are og:title, og:description and og:image:

<meta property="og:title" content="Repair Prices">
<meta property="og:image"
      content="https://www.example.com/images/workshop-800.jpg">

Use a full HTTPS URL for the preview image. These tags describe the shared card; they do not replace the visible page headings or its ordinary title and description.

Crawling is fetching pages, often by following links. Indexing is storing information about those pages for search results.

Give every page a route in

Link each page from at least one other page with an ordinary <a href> link. Descriptive text such as "repair prices" tells visitors and crawlers what the target contains. A readable path such as /blog/winter-checklist.html gives more context than /page7.html.

A sitemap lists the full preferred URLs you want discovered. An XML entry can look like this:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/prices.html</loc>
    <lastmod>2026-10-01</lastmod>
  </url>
</urlset>

The optional last-modified date should represent a significant change. Update the sitemap as pages change. A small, well-linked site can be discovered without a sitemap.

Keep crawling and indexing controls distinct

A robots.txt file at the domain root asks compliant crawlers which paths not to fetch:

User-agent: *
Disallow: /drafts/
Sitemap: https://www.example.com/sitemap.xml

This does not lock the folder. People can open its addresses, and a blocked URL may still appear in results if other pages link to it. Without a robots.txt file, crawlers are allowed to fetch pages. A copied Disallow: / blocks crawling across the site, so remove a test-site block before launch when the site should be crawled.

To request exclusion from search results, put this in the page's head:

<meta name="robots" content="noindex">

The crawler must fetch the page to read that instruction. Blocking the same URL in robots.txt can stop it from discovering noindex. Neither setting makes a page private: private content needs access control or must stay off the public site.

Choose one address for duplicate content

A page may answer at HTTP and HTTPS addresses, with and without www, or at both /blog/ and /blog/index.html. A canonical link identifies the preferred address:

<link rel="canonical" href="https://www.example.com/blog/">

Use the full absolute URL. Canonical markup is a strong hint; a redirect that actually sends visitors to the preferred address is a stronger signal. Match internal links and sitemap URLs to that preference to avoid sending conflicting signals.

Check what search engines can see

Google Search Console and Bing Webmaster Tools accept sitemaps and show indexing and crawl problems after you verify site control. A site:example.com search gives a rough view of indexed pages. New sites may take days or weeks to appear. A sitemap, clean markup or a payment cannot guarantee a high ranking; these tools help you find technical obstacles and understand what has been processed.

A static website serves prepared HTML, CSS, image and script files. Its content can be updated whenever you publish new files; "static" describes how the host serves them. The hosting server keeps delivering them when your own computer is switched off.

Know what the host provides

A dynamic site builds responses on the server, often from a database. A small informational site or portfolio built with HTML and CSS can use static hosting without server-side programming. Adding a contact form's markup does not by itself create a service that stores or emails submissions. That requires host-provided form handling or a separate service.

Static hosts commonly provide a temporary address, publishing controls and HTTPS. Many serve files through a content delivery network, which keeps regional copies. GitHub Pages, Netlify, Cloudflare Pages and Vercel are examples, with different plan terms and workflows. Shared hosting is another option and often supports secure file transfer.

A static page can still run JavaScript in the visitor's browser, such as a menu interaction. The host still serves a prepared script file. With no site application code or database running on the server, there are fewer application components to attack; the hosting account and public files still need protection.

A GitHub Pages user site uses the root address https://username.github.io/ from a repository named username.github.io. A project site uses a subfolder such as /riverside-bikes/. That address structure matters when testing root-relative asset paths.

Compare needs with the current plan

Read the plan's limits and conditions before choosing. Check:

• Storage and monthly data-transfer allowances.
• Whether the plan permits commercial use.
• Custom-domain support and automatic HTTPS.
• A publishing method you can use reliably.
• Custom error pages, redirects and previous-deploy recovery.
• Form handling if visitors must submit information.
• How easily you can take your files to another host.

A photographer's six-page portfolio with 40 prepared photos fits the size of many free static plans. If it attracts paid work, however, its commercial purpose also matters. Size alone does not establish that a free plan permits it. Terms change, so check the actual service and plan rather than relying on an old comparison.

Pick a manageable publishing route

Drag-and-drop publishing can suit a small project: you upload the folder through the host's interface. A repository connection publishes from a chosen stored code source and can deploy updates when changes are pushed. Command-line tools offer another route. Shared hosting often supports SFTP, an encrypted file-transfer method. Plain FTP exposes credentials and files during transfer, so use a secure route.

For GitHub Pages on a free plan, publishing is available from public repositories. Anyone can read the repository files. Published assets are public too, even when navigation does not link to them. Keep the upload limited to intended public files and protect the hosting account with two-factor authentication.

Check a feature in its actual workflow

If the site includes a contact form, locate the form endpoint or host feature that receives it. Confirm the plan includes that feature and send a test submission after launch. A form that looks complete can still have nowhere to send data. If a custom 404 page or permanent redirect matters, confirm the host's exact configuration method before depending on it.

To deploy is to publish the current site files to a host. The publish directory becomes the site's root online. For plain HTML and CSS, there is no build step: select the folder containing the finished index.html and its assets.

Make the first release

For a drag-and-drop host:

1. Open the folder you intend to publish and confirm that index.html is directly inside it.
2. Validate the pages and test their links and layout through a local server.
3. Upload that folder using the host's publishing interface.
4. Wait until the host reports the deployment is live.
5. Open its supplied web address and check the site there.

If the home page appears only at /riverside-bikes/index.html, you may have uploaded the containing folder one level too high. The intended publish directory is riverside-bikes/, not the folder holding it. Fix the directory selection and publish again; merely linking visitors to the nested address leaves the bare home address wrong.

Publish from a repository

In GitHub Pages, open the repository's Settings and Pages. Choose "Deploy from a branch", then select the branch and publishing folder, either its root or /docs, and save. When a new version is pushed to that publishing source, Pages deploys it again. Check the displayed Pages address after the deployment finishes. A project URL may include the repository name, so test paths at that actual location.

Other hosts have their own repository connection and directory settings. For a site made from plain files, do not add a build command simply because the interface offers a field for one.

Check the delivered version

Open every page, follow internal links and inspect Console and Network for failed resources. Force a full reload to avoid mistaking cached files for the new release. Try the site on a real phone. Check the visible change you intended to publish, not just the absence of an error message.

Configure a custom 404.html where the host supports it. It should tell the visitor that the address was not found and provide a useful way home. Check an invented missing address to verify the host actually uses it. A helpful error page does not replace a redirect when the content has moved.

Keep a source you can recover

The local project or connected repository is the source of truth, the copy from which future releases are made. A quick correction in a host's web editor can disappear on the next upload unless you also put it into that source.

Use a preview deployment when available to test an update before visitors receive it. If an update breaks the live site, a host's rollback can restore a previous deployment. Then correct the source too, or the next release may reintroduce the fault.

When a page changes address, add a permanent 301 redirect from the old URL to the new one using the host's redirect rules. Test the old address after publishing: it should lead to the intended new page. On Netlify, a _redirects file is one configuration route; other hosts use different settings.

A domain name is a readable name such as example.com. DNS connects that name to information such as a host's IP address. Registration gives you the right to use the name for a period; it is not a permanent purchase.

Read a web address

In https://www.example.com/prices.html, https is the scheme, www.example.com is the host name and /prices.html is the path. Read the domain labels from right to left: .com is the top-level domain, or TLD; example is the registered name under it; www is a subdomain.

Generic TLDs include .com, .org, .net, .dev, .shop and .studio. Country-code TLDs use two letters, such as .de, .fr, .jp, .ca and .au. Some names are registered under a second-level category, such as .co.uk.

Some endings have eligibility rules. .ca requires a Canadian connection; .eu accepts eligible EU or EEA citizens, residents and established organizations; .us requires a US connection. Check the registry's rules before choosing a restricted ending. The .dev and .app endings require HTTPS in browsers.

Know who handles registration

A registrar records your registration with the registry that operates the TLD. ICANN coordinates the generic TLD system and accredits its registrars; country-code registries set their own rules. Registrations commonly last from one to ten years and need renewal.

Choose a name that is short, easy to say and spell, and close to the project or business name. Avoid confusing numbers and hyphens, and check that the name does not use someone else's trademark. If a preferred .com name is taken, compare a clear longer name, a suitable local ending or a relevant generic ending. Availability alone is not permission to use another business's name.

Compare the ongoing commitment

Check the renewal price as well as the first year's offer. Extra services, including email, may have separate charges. The domain and the website hosting can come from different companies; registering a domain does not by itself upload a website.

Provide accurate owner and contact information and respond to the registrar's verification email. Unconfirmed contact details can lead to suspension. For generic TLD registration information, RDAP became the definitive public lookup route in January 2025, replacing the older WHOIS service requirements. Public lookup commonly hides personal details; the registrar still needs accurate records.

Keep control with the owner

The project or business owner should control the registrant account, even when a designer builds the site. Enable two-factor authentication and keep recovery details current. To change registrars, follow the transfer process, including a transfer code and unlocking the domain when eligible.

Record the expiry date, enable renewal and keep the payment method valid. An expired registration can interrupt the website and domain email; after applicable grace and deletion periods, another person may register the name. Hosting backups cannot preserve a domain registration you let lapse.

The Domain Name System, or DNS, stores records for names. A resolver looks up those records, often keeping a cached answer. The authoritative nameservers are the servers responsible for the domain's DNS information. Make changes at the provider whose nameservers actually serve the domain.

Choose the record type

The IP addresses and .example name here are documentation values. For a real connection, use the values supplied by your host for your site.

The apex is the registered root name, such as example.com. Standard DNS does not permit a CNAME there because the apex also needs other records, including NS. Use the host's A and AAAA values, or a provider-supported ALIAS, ANAME or CNAME-flattening feature. A subdomain such as www commonly uses a CNAME.

Connect two forms of an address

Suppose a host asks for an apex A record and a www CNAME. A provider that uses @ for the apex might show:

Type    Name    Value                           TTL
A       @       192.0.2.44                       3600
CNAME   www     riverside-bikes.pages.example    3600

Enter the custom domain in the hosting settings too. The host must recognize the requested name and assign it to the site. Choose the main address and configure the other form to redirect to it.

Read the provider's name-field instructions. If it automatically adds example.com, typing www.example.com may create www.example.com.example.com. Remove obsolete address records when replacing a host; leaving both old and new values can send visitors to different servers.

Allow cached answers to expire

TTL, time to live, states how many seconds a DNS answer may be cached. A TTL of 3,600 is one hour; 86,400 is 24 hours. After an update, different visitors can temporarily receive different answers. Changes may take 24 hours or longer to be seen everywhere.

For a planned move, lower the TTL to 300 seconds at least one old TTL period before switching. Lowering it at the moment of the switch cannot shorten the lifetime of an answer already cached under the old TTL.

Move DNS without losing other services

You can leave DNS with the registrar and edit records, or change nameservers to a new provider. A nameserver change does not copy records. Recreate and check the required MX, TXT and other records at the new provider before switching, especially when domain email already works.

Check answers with nslookup www.example.com, dig example.com A +short or a DNS lookup service, and compare them with the host's settings. Add wildcard records only deliberately and where the host supports them. When removing a hosted site, remove DNS records pointing to it too; a forgotten alias may allow another person to claim the abandoned host target.

HTTPS sends HTTP over an encrypted TLS connection. It protects the privacy and integrity of data in transit and lets the browser authenticate the server for the requested domain. Plain HTTP exposes data to people who can observe the connection.

A certificate identifies the domain

A TLS certificate binds a domain name to a public key and is signed by a trusted certificate authority, or CA. It lists the names it covers and its expiry. If visitors use both example.com and www.example.com, the certificate coverage must include both names, even when one redirects to the other: the browser connects securely before receiving that redirect.

An HTTPS connection is not a judgment about the honesty of a business. A fraudulent site can obtain a certificate for a name it controls. The connection's protection and the site's trustworthiness are separate questions.

Let the host issue and renew it

Many static hosts automatically request a free certificate, often from Let's Encrypt, once DNS points to the host and the domain is configured. The CA checks control of the name, for example through a DNS record or a file fetched over the web. Issuance can take minutes to about a day.

As of October 2026, newly issued publicly trusted TLS server certificates have a maximum lifetime of 200 days under the rules effective March 15, 2026. The maximum becomes 100 days in March 2027 and 47 days in March 2029. Let's Encrypt's default classic certificates currently last 90 days, with shorter profiles also available. Automatic renewal avoids having to repeat this work manually.

For a 90-day example, a certificate issued on March 1, 2026 expires on May 30. Renewal with 30 days remaining would occur around April 30. The actual expiry and renewal status are available through the host or certificate details; do not assume a working domain registration also means the certificate is current.

Redirect to HTTPS and fix insecure assets

Turn on the host's HTTPS enforcement. It redirects http:// requests to the HTTPS address, commonly with status 301 or 308. Also choose one main host name, with or without www, and redirect the other to it.

Mixed content occurs when an HTTPS page requests a resource through http://. Browsers block insecure scripts, style sheets, frames and fonts. They try to upgrade some media requests to HTTPS, which fails if the source cannot serve it. Check Console messages and search the code for http://. Use relative paths for your own files and working HTTPS URLs for external resources.

HSTS, HTTP Strict Transport Security, tells browsers to use HTTPS for a set period. Enable it when HTTPS works reliably; browsers that have received the policy will not fall back to plain HTTP during that period. The .dev and .app endings are preloaded for HTTPS-only behavior.

If a certificate warning appears after connecting a domain, check DNS, issuance status and name coverage. The bare domain can work while www fails when only the bare name is covered. Correct the configuration and wait for issuance where needed; visitors should not bypass a certificate warning.

A live site changes even when its files do not. External links move, contact details become outdated, domains approach expiry and third-party widgets change. Maintenance keeps the content correct and the delivery reliable.

Follow the same route for every update

Edit the local project or repository, test in a browser, validate the affected code, deploy, and verify the live pages. Make a preview when the host supports one. Check a successful correction in the copy used for future releases so it cannot be lost in the next upload.

A content change deserves a content check too. Confirm dates, opening hours, prices and contact details against their current source. Give pages an owner or review date. Remove or replace information that no longer describes the service; an old event notice can mislead visitors even when every tag is valid.

Check links and visitor tasks

Link rot is the gradual failure of links as target pages move or disappear. Use a link checker such as the W3C Link Checker, then verify and repair the reported failures. When your own page moved, a redirect preserves old inbound links. For an external page, update the target or remove the link when no useful replacement exists.

Try real visitor tasks. Send a contact-form test and confirm it arrives. Follow navigation with a keyboard. Test a phone layout. An uptime check that receives a page cannot establish that a form or navigation works.

Keep recoverable copies

Back up the source and required assets in at least two places, such as a computer plus an external drive, cloud storage or repository. A hosting account problem or mistaken deployment can remove the live copy, so the live host is not your only backup. Version history can make earlier versions recoverable. Keep enough information to reconnect the domain and republish the site.

Protect renewals and account access

Enable domain auto-renewal and keep the payment method valid. Check the expiry date and confirmation messages. Make sure registrar and host accounts use two-factor authentication and current recovery details. Certificate renewal also depends on a working domain configuration, so check HTTPS after DNS changes.

An uptime monitor checks the site repeatedly and alerts you when it stops responding. Webmaster tools can reveal crawl failures and 404s from old addresses. Review those reports, then test the underlying problem rather than assuming every alert has the same cause.

Schedule work by the kind of change

Third-party fonts, scripts, maps and other embeds may slow down, change or disappear independently of your site. Keep them few and review whether they are still needed. Where a license permits, hosting a local copy of an asset can reduce dependence on another server. Recheck its license and update needs when replacing it.