Technical SEO for Company Websites: A Complete Checklist

Technical SEO is everything that decides whether search engines can find, render and correctly understand your website, before your content and reputation get a chance to compete. A complete technical SEO checklist for a company website covers six areas: crawling, indexing, site structure, speed and mobile experience, structured data, and security with ongoing monitoring. A single mistake in one of them, such as a leftover "noindex" tag, can hide an otherwise excellent site.

Most company websites, with a few dozen to a few thousand pages, rarely need exotic tricks. They need the basics done correctly at launch, then checked again after every redesign, CMS change or major release, because that is when things quietly break.

The checklist below is grouped by area, with notes on who usually owns each fix, so you can hand it to your developer or agency and track progress.

Before you start: tools, owners and priorities

You can run most of this audit with free tools:

• Google Search Console for the Page indexing report, URL Inspection, Sitemaps and the Core Web Vitals report
• Bing Webmaster Tools for similar data from Bing
• PageSpeed Insights for performance data from real Chrome users plus a lab test
• A crawler that walks your site the way a search engine does. The free version of Screaming Frog SEO Spider handles up to 500 URLs, which covers many company sites

Technical SEO sits between marketing and engineering, so agree on owners before you find problems. A simple split:

Fix in this order: anything that blocks indexing, then template-level issues that affect many pages at once, then individual pages. A broken canonical tag in a template deserves more attention than one slow blog post.

Crawling and indexing

If search engines cannot crawl a page, or are told not to index it, nothing else on this list matters.

robots.txt

• The file exists at the root of the domain and returns a 200 status
• It does not block CSS, JavaScript or image folders that pages need to render
• It does not contain "Disallow: /" copied from a staging server. This is one of the most common launch mistakes
• It points to your XML sitemap
• Your policy for AI crawlers, such as OpenAI's GPTBot or the Google-Extended token, is a deliberate decision rather than an accident

Remember that robots.txt controls crawling, not indexing. To keep a page out of search results, use a noindex meta tag or X-Robots-Tag header, and leave the page crawlable so the tag can be seen.

XML sitemap

• It lists only canonical URLs that return 200 and are meant to be indexed
• It updates automatically when pages are published or removed
• It is submitted in Search Console and Bing Webmaster Tools, with no errors reported

Status codes and redirects

• Removed pages return a real 404 or 410, not a "page not found" message served with a 200 status (a soft 404)
• Permanent moves use 301 or 308 redirects that point directly to the final URL, without chains
• HTTP and HTTPS, and www and non-www, all resolve to one preferred version

Duplicates and canonical tags

• Every indexable page has a canonical tag pointing to itself
• Tracking parameters, sort orders and session IDs do not create separate indexable pages
• Trailing slashes and capital letters in URLs are handled consistently

JavaScript rendering

Google can render JavaScript, but content that exists only after scripts run is easier to miss. Check that key text and links appear in the HTML the server sends, and use URL Inspection to view the rendered page. Navigation should use real links with href attributes, not click handlers. Frameworks with server rendering make this much easier, one of the reasons we covered in Next.js for business websites. If you are still choosing a CMS, our comparison of headless CMS and WordPress for SEO shows how each option affects rendering.

Site structure, URLs and internal links

Structure tells search engines which pages matter most.

• Shallow hierarchy. Important service and product pages should be reachable within a few clicks of the homepage
• Readable URLs. Lowercase words separated by hyphens, such as /services/inventory-system. Avoid dates in URLs for evergreen pages, and never change URLs without redirects
• No orphan pages. Every indexable page should be linked from at least one other page. Landing pages built for ad campaigns are frequent orphans
• Descriptive anchor text. "Warehouse management system" tells search engines far more than "click here."
• Breadcrumbs on deeper pages, marked up with BreadcrumbList structured data
• Pagination with real links. Google no longer uses rel="prev" and rel="next" as an indexing signal, so paginated lists need ordinary links between pages
• Controlled filters. Product catalogs with filters for brand, size, color and price can generate thousands of near-duplicate URLs. Decide which filter combinations deserve their own indexable page and keep the rest out of the index

Structure is most at risk during a redesign. If you are planning one, follow the URL mapping steps in how to redesign a website without losing SEO before launch day, not after.

Speed, Core Web Vitals and mobile

Core Web Vitals are Google's field metrics for loading, responsiveness and visual stability. A page passes when at least 75% of real visits meet each "good" threshold.

INP replaced First Input Delay as a Core Web Vital in March 2024, so older audit reports may show a metric that no longer counts. For the business case behind these numbers, see Core Web Vitals explained.

Checks for this area:

• Search Console's Core Web Vitals report shows mostly "Good" URLs for both mobile and desktop. Low-traffic sites may have no field data, so use lab tests as a guide
• Hosting or a CDN with servers close to your visitors. If most of your buyers are in Indonesia, a server in the United States adds delay to every request
• Third-party scripts are audited. Many Indonesian company sites load a WhatsApp chat widget, a live chat tool and several advertising pixels on every page. A plain wa.me link often does the same job as a heavy widget
• Images use WebP or AVIF where possible, with lazy loading below the fold but never on the main hero image

Mobile deserves its own line. Google indexes the mobile version of your pages, so the mobile layout must contain the same content, links, structured data and metadata as desktop. Content inside tabs or accordions is fine; sections that disappear on mobile are not. Test on a mid-range Android phone over mobile data, which is closer to how many of your buyers see the site than a developer laptop on office Wi-Fi.

Metadata, structured data and bilingual pages

Titles, descriptions and link previews

• Every page has a unique title that leads with its topic and ends with the brand name
• Meta descriptions are unique and written to earn the click. They are not a ranking factor, and Google sometimes rewrites them, but a good one still helps
• Each page has one clear H1
• Open Graph tags (og:title, og:description, og:image) are set. WhatsApp, LinkedIn and Facebook use them for link previews, and a broken preview in a WhatsApp group looks careless

Structured data

• Organization markup with your company name, logo and links to official profiles
• LocalBusiness markup for offices or showrooms, with an address and phone number that match your Google Business Profile
• Article markup on blog posts, Product markup on catalog pages and BreadcrumbList on deep pages
• Markup matches what is visible on the page and passes Google's Rich Results Test

Do not add FAQ markup expecting expandable results in search. Since 2023, Google shows FAQ rich results only for a small set of well-known government and health websites.

Indonesian and English versions

Many Indonesian companies need both languages. The checks:

• Each language lives on its own URL, for example /id/ and /en/, rather than being toggled by a script on one URL
• hreflang annotations link each version to the other, plus an x-default. Use "id" as the language code for Indonesian; the old code "in" is obsolete
• Titles, descriptions and image alt text are translated too, not only the body text
• Visitors are not automatically redirected by IP address, which can also stop crawlers from seeing one of the versions

Security, monitoring and release checks

HTTPS is the baseline: a valid certificate, every page served over HTTPS and no mixed content warnings. Security problems become SEO problems quickly. Hacked sites are often injected with hidden spam pages, and online gambling spam has been a well-known problem on compromised Indonesian websites, including government and university domains. Search Console lists detected problems under Security issues, and our website security checklist covers prevention.

Monitoring routines that catch problems early:

1. Turn on Search Console email alerts and assign someone to read them
2. Review the Page indexing report monthly. Look for sudden jumps in "Excluded by 'noindex' tag", "Not found (404)" or "Crawled - currently not indexed"
3. Monitor uptime and server response time. Repeated server errors cause crawlers to slow down
4. Check server logs occasionally to see which sections search engine bots actually crawl
5. Repeat the full crawl quarterly and compare it with the previous one

Most technical SEO damage happens at deployment, so add automated checks to your release process. A build should fail if a production page contains a noindex tag, if robots.txt blocks the whole site, if the sitemap returns an error, or if key templates lose their canonical or hreflang tags. These checks are cheap to set up and prevent the expensive kind of mistake: the one you discover weeks later in falling traffic.

How Weaveward can build this for you

We would start with a technical audit of your current site: a full crawl, a review of your Search Console and Core Web Vitals data, and a prioritized fix list where every item has an owner and an effort estimate. Template-level fixes such as rendering, canonical and hreflang tags, structured data and image handling come first, because one change repairs every page that uses the template.

If the site needs a rebuild, our website and web app development team would build these checks into the project from day one: server-rendered pages, generated sitemaps, bilingual routing and automated release checks that stop a stray noindex before it ships. If you would like a second opinion on your current site, talk to our team.