Get Found Online
Build a Website
AI Systems
How It Works
Proof & Results
Pricing
Resources
About / Contact
Get my free visibility check
WORKING RESOURCE · PRINTABLE CHECKLIST

Technical SEO checklist. Crawl to conversion.

Use this checklist to organise an initial technical review. Record the URL, observation, date and next action for each finding. The checkboxes are a local session aid; they do not scan your website or send your results anywhere.

Technical scan · 48 pagesSample
robots.txt allows crawlingOK
XML sitemap found · 48 URLsOK
3 pages return 404 from internal linksFIX
Canonical mismatch on /services/CHECK
HTTPS everywhere · no mixed contentOK
LCP 3.4s on mobile homepageCHECK
Structured data valid · Organization, ServiceOK
7 images without width/heightCHECK
Quick answer

A technical SEO checklist covers crawl access (robots.txt, sitemaps, status codes), indexing (canonicals, noindex, duplicates), performance (Core Web Vitals on mobile), structure (internal links, structured data) and change safety after updates or migrations.

This checklist is a working aid for a business owner, marketer or developer in Malaysia who wants to check the technical health of a website without buying a tool first. Work through it with the site open in one tab and Google Search Console in another. Each section says what to check, what "good" looks like, and a common local mistake. It does not run anything automatically.

1. Can the important pages be reached?

Start with the ten to twenty pages that matter most: the homepage, each main service or product category, pricing, contact and any location pages. Open each URL and check its HTTP status with your browser's developer tools or a free header checker. A public page should return 200. A moved page should return a single 301 to a relevant destination. A deleted page should return 404 or 410, not a 200 "page not found" message, which search engines call a soft 404.

Check the assets too. If the stylesheet or main script fails to load, the page Google renders may look nothing like the one you see.

Common local mistake: the site moved from http to https, or from www to non-www, and old links now pass through two or three redirects. Collapse chains into one hop.

2. Are crawl and index controls intentional?

Read /robots.txt and look at the robots meta tag on key pages. Blocking a URL in robots.txt stops Google reading it, which also means Google cannot see a noindex on that page. Use one control or the other, deliberately.

Do not remove every noindex you find. Thank-you pages, internal search results, cart and account pages are often excluded on purpose. The question is whether each control matches the page's purpose.

SampleA fictional renovation contractor in Shah Alam

The web designer built the new WordPress site with "Discourage search engines from indexing this site" switched on during development, and it was never switched off at launch. Three months later the owner wonders why enquiries from Google dried up. Search Console's Page indexing report shows most pages "Excluded by 'noindex' tag".

The fix takes one click; the lesson is to check indexing controls on launch day and after every major update.

3. Do URL signals point to the same place?

For each important page, the canonical tag, the internal links and the sitemap entry should all use the same final URL: same protocol, same host, same trailing slash. Look for canonicals pointing to a staging domain, to the homepage, or to a URL that redirects.

  • Your XML sitemap should list only indexable, canonical URLs that return 200, and should be referenced in robots.txt and submitted in Search Console.
  • A sitemap helps discovery. It is not a substitute for redirects and does not force Google to accept your chosen canonical.
  • If the site has English and Bahasa Malaysia versions, each version should canonicalise to itself and the two should reference each other with hreflang (for example en-MY and ms-MY).

Common local mistake: a staging copy on a subdomain such as dev. or staging. is publicly indexable and competes with the real site. Protect staging with a password.

4. Is the main content actually in the page?

View the page source and the rendered page. If the service description, prices or navigation only appear after JavaScript runs, confirm with Search Console's URL Inspection "View tested page" that Google sees them too. Links should be ordinary <a href> elements, not click handlers on a div.

Check that each page has one clear <h1>, headings that describe the sections, a unique <title> and meta description, and useful alt text on meaningful images. A product photo named IMG_4021.jpg with no alt text tells nobody anything.

5. Does the mobile journey work on a real connection?

Most Malaysian visitors arrive on a phone, often on mobile data. Open each key page at around 390px wide and check for horizontal scrolling, overlapping buttons, tables that break the layout, pop-ups that cover the content and a WhatsApp button that hides the text. Try to complete the path to an enquiry: find the price, tap WhatsApp or call, and see what message is pre-filled.

For speed, separate lab data (a single PageSpeed Insights run) from field data (Core Web Vitals collected from real Chrome users, shown in PageSpeed Insights and in Search Console when there is enough traffic). Core Web Vitals measure loading (LCP), responsiveness (INP) and visual stability (CLS). Typical culprits on small business sites: uncompressed hero photos straight from a phone camera, several page builders and sliders loading on every page, chat widgets, and cheap shared hosting located far from Malaysia.

6. Do structured data and business facts match reality?

Check your JSON-LD with the Rich Results Test or the Schema Markup Validator. Organization or LocalBusiness markup should carry the same name, address, phone number and opening hours shown on the page and on your Google Business Profile. Do not add review stars, ratings, authors or addresses just to fill a template; structured data must describe what visitors can actually see. Fake review markup is a spam risk, not a shortcut.

Every important page should be reachable within a few clicks of the homepage and linked from related pages with descriptive anchor text such as "kitchen cabinet installation in Klang", not "click here". Look for orphan pages that nothing links to, and for broken internal links after pages were renamed. A crawler such as Screaming Frog (free up to 500 URLs) will list both.

8. Did the change fix the actual output?

After any technical fix, revisit the affected URL and confirm the intended state: the status code, the canonical, the robots tag, the copy or the link. Keep a simple before-and-after record with the date. Then use Search Console to watch indexing and search data over the following weeks, as a separate observation. A technically correct site is necessary for good rankings; it does not guarantee them.

Plan larger changes carefully. Before a redesign or a move to a new platform, list every existing URL, map each one to its new address, and set up 301 redirects before launch. Most traffic losses after a Malaysian SME redesign come from skipping this step.

How to prioritise what you find

You will find more issues than you can fix at once. Fix, in this order: anything blocking important pages from being crawled or indexed; anything breaking the path to an enquiry; wrong canonicals and redirect chains on key pages; mobile layout problems; then performance and structured data. A warning on a page nobody visits can wait.

If you want this done continuously rather than once, that is what Vyntra's technical agent does every day as part of technical SEO. You can also start with a free SEO audit, or read how to use Search Console for SEO to check indexing yourself.

Sources & further reading

External sources reviewed 21 September 2026. Platform guidance describes eligibility and good practice, not guaranteed outcomes.

Written by the Vyntra team · Reviewed 27 September 2026

FAQ

Questions people ask

Will ticking this checklist run an audit?

No. This is a manual working aid. It does not fetch your site, run tests or store anything. For an automated check, ask for a free SEO audit.

Should every warning be fixed first?

No. Prioritise confirmed issues on important pages and on the path to an enquiry. Some warnings are low-impact or need more evidence.

How often should technical SEO be checked?

Key pages should be monitored continuously or at least weekly, and every time the site, theme or plugins are updated. A full crawl monthly is sensible for most SME sites.

Do I need a developer to fix these issues?

Many fixes, such as indexing settings, titles and redirects in WordPress, can be made by the site owner. Template, JavaScript and hosting issues usually need a developer.

See what your website is missing.

A free audit from the same system that runs your SEO. You get a clear list of priorities on WhatsApp within 2 working days.