Getting a website ready to launch

The pages are done. What’s often missed are the small things around them: the icon in the browser tab, the card that appears when someone shares a link, what search engines show and may crawl, and the headers that protect visitors. These tools make and check each one from files and text you paste; none of them fetch your site.

1. Icons

Drop a square logo, ideally an SVG or a PNG of 512 pixels or more, on the Favicon Generator. Set the background and padding for the Apple and Android icons, which get cropped and filled, and Save the icons. Put the files in the site’s top folder and paste the tags it gives into each page’s <head>. A simpler version of the logo often reads better at 16 pixels.

2. Share cards

Paste a page’s <head> into Social Card Preview, and choose the share image too. It shows the card as the main apps draw it, lists what’s missing (an og:image, a description, an image under 1200 × 630 for a wide card) and gives a full set of tags to copy. Apps cache cards, so get them right before the link is first shared.

3. Structured data for search results

If pages describe products, articles, events, recipes or FAQs, schema.org markup lets search engines show prices, dates, ratings or questions under the link. Paste a page’s HTML from View Source into the Structured Data Viewer. Every JSON-LD, microdata and RDFa item is shown as a tree, and properties Google lists as required for its rich results are flagged when missing, such as a Product with no offers. Check a template page of each kind, as one fix covers every page built from it. Passing doesn’t promise a rich result: confirm with Google’s Rich Results Test once the site is live.

4. robots.txt and the sitemap

Paste your robots.txt into the robots.txt Tester, pick a crawler and list some paths. Each is marked Allowed or Blocked with the rule that decided it. Check the important pages are allowed, and that a Disallow: / left over from a staging site hasn’t come along. AI crawlers are in the list if you want to decide about them separately.

Then open the sitemap.xml your site generates in the Sitemap Inspector. Every page should be listed with its full https:// address on the live domain: a staging host or localhost left in the addresses is a common slip. Fixing sitemap errors covers what the checks mean.

5. Security headers

Once the site is up, run the curl -sI command Security Headers & CSP shows, or copy the response headers from the browser’s Network tab, and paste them in. The six main headers are graded A+ to F, with notes on cookies missing Secure or HttpOnly and on headers that give away software versions. Build a policy helps write a Content Security Policy; test a strict one before relying on it, as it can stop parts of a site working.

A strict policy blocks inline scripts and styles unless they’re allowed by hash. Paste the page’s HTML into SRI & CSP Hashes to get a 'sha256-…' or 'sha384-…' source for each inline <script> and <style>, ready for script-src and style-src; any change to that code, even a space, needs a new hash. For libraries loaded from a CDN, drop the exact file you tested with on the same page to get the <script> tag with its integrity attribute, so the browser refuses a copy that’s been changed.

6. The certificate

Click the padlock in the browser to view and export the site’s certificate, or run openssl s_client -connect example.com:443 -showcerts, and paste the PEM into the Certificate Decoder. Check the alternative names cover every address you use (with and without www), and note when it expires. Paste the whole chain to check each certificate was issued by the next.