Coder Legion - Recent posts tagged sitemap

SEO Checklist for Indie Hackers: Sitemap, Schema, and llms.txt — the Three Files That Do the Talking

Tue, 27 Oct 2026 12:59:22 +0000

Most indie SEO advice is a list of things to write: more posts, better titles, target this keyword. That advice is not wrong, exactly. It is just the second half of the job, and it assumes the first half already happened — that search engines and AI assistants can actually find, understand, and trust your pages.

I run NitroIDE, a browser IDE on a static host with no server, no build step, and no plugin system. There is no SEO plugin to install. Everything machine-readable on the site is a file I wrote by hand or a script I maintain. That constraint turned out to be useful: it forced me to learn which three files actually matter, what each one is for, and how each one silently breaks.

Here is the checklist, in the order I would do it again.

1. The sitemap: prove every page exists

A sitemap is a list of your URLs, with a last-modified date for each, handed to search engines in a format they can crawl without guessing. It does not make a bad page rank. It makes a good page findable — especially on a site where new pages arrive one at a time and internal linking is thin.

The checklist for a sitemap:

Every page goes in, no exceptions. This is a rule I set for myself after redirect stubs got left out once: if a page exists and you want it found, it is in the sitemap. A sitemap that quietly omits pages is worse than no sitemap, because you stop checking.
Lastmod must be real. A lastmod date that never changes teaches crawlers to ignore your dates. Mine come from git history: the last commit that touched each page sets its lastmod. That is automated, so it cannot drift from reality the way a hand-edited date can.
Submit it, then check the report. A sitemap sitting in your repo root that nobody submitted is a wish, not a signal. Submit it in Search Console and read the coverage report: pages discovered, pages indexed, and — the useful part — the pages excluded and why.
Regenerate it when you publish. My publishing flow refreshes the sitemap with every new blog post. A sitemap that is stale on publish day is a sitemap that tells crawlers the new page does not exist yet.

The mistake that silently voids a sitemap is staleness, not syntax. Syntax errors show up loudly in the report. A sitemap that is valid but three months old just quietly stops describing your site.

2. Schema: tell machines what the page IS

If the sitemap says “these pages exist,” schema says “and here is what each one is.” JSON-LD is the format: a block of structured data in the page that names the thing — a software product, a blog post, a FAQ — in a vocabulary search engines already understand.

For an indie site, three types cover almost everything:

SoftwareApplication for the product itself: name, description, operating system, offers (free, in my case), and version. This is the one that lets a search result describe your tool as a tool, not as a generic webpage.
BlogPosting for articles: headline, author, date published, and date modified. The date-modified field matters more than people think — it is how a corrected, updated article signals that it is current rather than old.
FAQPage for pages that genuinely answer questions: a list of question-and-answer pairs, each complete in itself. Only use it where the page actually contains those answers visibly. Schema that describes content the page does not show is the fastest way to lose trust in all your schema.

Three rules for schema that I wish someone had given me earlier:

Validate before shipping, not after indexing. A structured-data testing tool will catch a missing comma or a wrong type in seconds. Waiting for Search Console to report it costs you a crawl cycle.
Match the visible page. Every fact in the schema should be findable by a human reading the page. If the schema claims a price, a rating, or a feature the page never mentions, that is not optimization — it is a mismatch waiting to be flagged.
Keep it boring. Schema is not the place for creativity. Use the standard types, the standard property names, and nothing clever. The whole point is that a machine on the other end already knows what these words mean.

The mistake that silently voids schema is the same as the sitemap's, in a different costume: schema that describes last month's page. When you change a price, a version, or a headline, the schema changes in the same commit, or it becomes a lie told in a format machines trust.

3. llms.txt: the file for readers that are not browsers

Sitemaps and schema are for search engines. llms.txt is for a newer reader: AI assistants that want to understand your site without crawling every page and reconstructing the picture from fragments. It is a short, plain-text file at your site root that says what the site is, what its important pages are, and where to find them.

I added one recently, and it taught me something the other two files did not: a summary file is a second source of truth. A reader on Peerlist put it better than I did — llms.txt is like a contract summary versus the document itself. Useful, but only while it matches the document. The moment the site changes and the summary does not, the summary is not just stale, it is actively misleading the exact readers you wrote it for.

So the checklist for llms.txt is short and strict:

Keep it short. It is a map, not a mirror. Link to the real pages; do not paste their content in.
Update it with the site. When a new section ships or an old page goes away, the file changes in the same round of work. Treat it like the sitemap: maintained by the publishing flow, not by memory.
Say what the site is in one paragraph. The first lines are the whole pitch to a reader that will never see your homepage design. If those lines are vague, the rest of the file does not rescue them.

The mistake that silently voids llms.txt is neglect. Unlike a broken sitemap, which Search Console reports, a stale llms.txt produces no error. It just keeps answering questions about a site that no longer exists.

The whole checklist, on one screen

Sitemap: every page in, lastmod from a real source, submitted, refreshed on publish.
Schema: SoftwareApplication for the product, BlogPosting for articles, FAQPage only where the page really answers questions — validated, matching the visible page, using standard types.
llms.txt: short, linked (not pasted), updated with the site, with a one-paragraph description that actually says what the site is.
After shipping, verify all three: Search Console coverage for the sitemap, a structured-data test for the schema, and a plain read of llms.txt to check it still describes the site you have.

None of this replaces writing something worth finding. But it is the difference between a good page that search engines and AI assistants can describe accurately, and a good page they have to guess at. Indie hackers do not have a marketing team to do the guessing for them. These three files are the team.

Non-Canonical URL in Sitemap: How to Fix It | FloxoLab

Sun, 04 Oct 2026 15:50:00 +0000

Direct answer: when a sitemap contains a non-canonical URL, remove that entry and list the preferred canonical page instead. If the listed URL redirects, use the final destination. The replacement should return a direct 200, allow indexing, and declare itself canonical.

The warning means the sitemap presents one URL as preferred while a redirect, rel="canonical", or Google's canonical selection points elsewhere. Do not replace every flagged URL blindly. Follow the redirect, inspect the declared canonical, and confirm that the destination is the page you actually want users to find. A bad destination should be corrected before it becomes the new sitemap entry. Cleaning the file does not guarantee crawling, indexing, or rankings.

Use this action table for each sitemap URL

Current result	What belongs in the sitemap	What else to fix
`200`, indexable, self-canonical	Keep the URL	Confirm internal links use the same version
`301` or `308` to a valid replacement	List the final destination	Update internal links and remove redirect chains
`302` or `307`	Usually keep the intended source out until the temporary state ends	Confirm whether the move is truly temporary
`200`, canonical points elsewhere	List the chosen canonical	Check that the pages are genuinely duplicate or very similar
`200` with `noindex`	Remove it	Keep or remove `noindex` based on the page's purpose
`404` or `410`	Remove it	Redirect only if a relevant replacement exists
Redirect loop, long chain, or broken target	List nothing until repaired	Point old URLs directly to one valid final page

The clean rule: one preferred content URL, one final 200 response, one matching canonical, and one sitemap entry. Redirect sources and duplicate variants can remain useful routes for visitors, but they should not be presented as preferred sitemap URLs.

Step 1: export the exact sitemap URLs

Open the sitemap in a browser or crawler and export every <loc> value. If the site uses a sitemap index, collect the child sitemaps first and keep a column showing which file supplied each URL. That makes template-specific problems easier to find, such as all product URLs using HTTP or an old category sitemap still listing redirects.

Google requires fully qualified absolute URLs and attempts to crawl them exactly as listed. Treat these as different entries until the server proves otherwise:

http://example.com/service
https://www.example.com/service/
https://example.com/service

A browser may hide the redirect between them. Your audit should not. Record the listed URL, first response, each redirect hop, final URL, final status, robots state, declared canonical, and whether the page is intended for search.

Step 2: crawl the list and follow every redirect

Use a crawler in list mode, a sitemap audit in your existing SEO tool, or command-line checks for a small file. Screaming Frog, for example, can crawl an uploaded URL list and export response codes, redirect chains, canonicals, and indexability in one table. The tool matters less than keeping the evidence together.

For one URL, these commands expose the first response and the final response after redirects:

curl -I https://example.com/old-page
curl -I -L https://example.com/old-page

Do not stop when the final response says 200. A chain such as old URL to trailing-slash URL to HTTPS URL still makes crawlers request three addresses. Update the sitemap and internal links to the last address, then simplify the redirect so every obsolete version points directly to it.

Google documents permanent server-side redirects, including 301 and 308, as strong signals that the destination should be canonical. Temporary redirects are handled differently because the source may remain the intended search URL. If a redirect has been "temporary" for months and the move is permanent, correct the response instead of working around it in the sitemap.

If the redirects belong to a redesign, CMS change, or domain move, use the full site migration SEO checklist to preserve the pre-launch crawl, map every old URL, test direct routes, and compare production after launch.

Step 3: compare the final URL with the declared canonical

On every final 200 page, read the canonical from the rendered HTML head or HTTP header. The ordinary healthy case is an absolute self-referencing canonical that exactly matches the final URL. Check protocol, hostname, path capitalization, encoded characters, and trailing-slash convention.

<link rel="canonical" href="https://example.com/services/seo-audit" />

If the page canonicalizes to another URL, inspect both pages. Keep the target in the sitemap only when it is a valid, indexable page and the two versions are duplicate or very similar. Google describes redirects and canonical annotations as strong signals, while sitemap inclusion is weaker. Stacking consistent signals helps. Listing both versions does not force Google to accept either one.

A canonical target that redirects, returns an error, is blocked, or has noindex is not a clean destination. Repair that target or choose the actual final page before updating the sitemap. If Google selected a different canonical than you expected, use URL Inspection to compare the user-declared and Google-selected values. The keyword cannibalization guide covers the separate case where two distinct pages overlap in intent and should not be treated as simple duplicates.

Step 4: decide whether each URL should exist in search

Sitemap cleanup is not only a status-code exercise. Ask whether each destination has a distinct job for users. Product variants, filters, print views, tracking URLs, internal search pages, thank-you pages, and staging paths may all return 200 while being poor sitemap candidates.

For the wider store diagnosis around crawl paths, category and product templates, pagination, filters, stock states, and Product markup, continue with the ecommerce SEO audit checklist.

Keep it: the page is useful, indexable, canonical, and meant to appear in search.
Consolidate it: the URL duplicates another page that should collect the signals.
Noindex it: users need the page, but it should not appear in search.
Remove it: the page is obsolete and has no useful replacement.

Do not redirect unrelated deleted URLs to the homepage merely to avoid a 404. Google warns against sending many old URLs to one irrelevant destination during site moves. A relevant replacement earns a permanent redirect. An intentionally removed page without a replacement can return 404 or 410 and stay out of the sitemap.

Step 5: fix the sitemap generator, not just the XML output

A manual deletion is temporary when the CMS, plugin, database query, or build script will add the URL back tomorrow. Find the source rule. Typical causes include published pages remaining in the sitemap after a slug change, a generator using database URLs before redirect normalization, duplicate language or protocol settings, and content types being included despite a sitewide noindex template.

Prevent the same variants at publication time with a documented SEO-friendly URL policy for hierarchy, slugs, parameters, case, trailing slashes, and redirects. This sitemap workflow repairs the inventory after a problem exists; the URL policy controls what the generator is allowed to create.

A healthy entry is simple:

<url>
  <loc>https://example.com/services/seo-audit</loc>
  <lastmod>2026-07-22</lastmod>
</url>

Set <lastmod> to the date of the last significant content change when your system can maintain it accurately. Do not refresh every date on every build. The sitemap should reflect the preferred URL inventory, not imitate constant freshness.

If you have several content types, generate them separately enough to diagnose. A sitemap index with pages, products, posts, and locations in distinct child files lets you isolate a bad rule and compare index coverage by sitemap without hand-editing thousands of rows.

Step 6: update internal links and canonical signals together

Removing a redirect from the sitemap while every navigation link still points to it solves only one symptom. Update menus, breadcrumbs, article links, hreflang references where applicable, and structured data to use the same preferred destination. The technical SEO fixes guide shows why stale links and bloated sitemap entries usually originate in shared templates.

Keep the old redirect for visitors and external links when it represents a real move. Sitemap cleanup does not mean deleting useful redirects from the server. It means the current site should stop discovering and advertising the obsolete address as if it were still the preferred page.

Step 7: validate the new file before submitting it

Regenerate the sitemap, crawl it again as a fresh list, and fail the check if any listed page does not meet the intended rules. For a standard indexable-page sitemap, the practical acceptance test is:

The sitemap itself returns 200, uses valid XML, and is accessible to Googlebot.
Every <loc> is an absolute URL on the intended host and protocol.
Every listed page returns a direct 200 without a redirect hop.
Every listed page allows indexing and names the same preferred canonical URL.
No duplicate, parameter, staging, deleted, or intentionally noindex URL remains.
Each <lastmod>, when present, reflects a real significant change.

Parse the XML as well as crawling the URLs. A technically perfect URL list still fails if special characters are not escaped, the namespace is wrong, or the file exceeds the protocol limits without being split.

Step 8: use Search Console for the right checks

Submit or resubmit the sitemap in the matching Search Console property. The Sitemaps report shows whether Google fetched and parsed that file. It does not certify that every listed URL is canonical, crawled, or indexed. Google explicitly describes sitemap submission as a hint and says not every URL is guaranteed to be crawled or indexed.

Open the Page indexing report and filter by the specific submitted sitemap. Watch the categories that motivated the cleanup, such as Page with redirect, Duplicate, Google chose different canonical than user, Excluded by noindex, or Not found (404). The report can lag behind the live site, so record the implementation date and read the report's last update before deciding the fix failed.

Use URL Inspection for a representative sample and every business-critical destination. The indexed result reflects Google's stored version. A live test checks the current fetch but does not test all canonical conditions or predict indexing. If a key page is still excluded, the Crawled - currently not indexed workflow provides the broader diagnosis.

What success looks like

Check	Immediate evidence	Later evidence
Sitemap file	Valid XML and direct `200`	Search Console can fetch and parse it
URL inventory	Only intended canonical pages remain	Submitted redirect and duplicate counts trend down
Redirects	Old URLs reach one relevant destination	Internal crawl no longer discovers redirect sources
Canonical signals	Final URL, canonical, links, and sitemap agree	URL Inspection increasingly shows the intended canonical
Indexing	Pages are technically eligible	Critical canonical pages are indexed when Google selects them

A clean sitemap is not an indexing command and does not promise rankings. Its value is operational: it gives crawlers, tools, and your team one defensible inventory of the pages the site intends to surface. When that list stays clean automatically, future redirect and canonical mistakes become visible instead of accumulating silently.

Practical questions

Will redirects in a sitemap hurt rankings?

A few stale entries are not evidence of a ranking penalty. They are maintenance debt and conflicting discovery signals. Replace them with the final canonical URLs, then judge the affected pages by their actual crawl, canonical, indexing, and performance data.

Should both a duplicate URL and its canonical be in the sitemap?

No. Google recommends choosing the preferred URL and listing it instead of every URL that leads to the same content. Keep duplicate routes only when users or systems need them, and align their canonical or redirect behavior with the preferred page.

Do I need to resubmit the sitemap after every change?

Google periodically recrawls a successfully submitted sitemap. Search Console says resubmission can make sense after big changes, while ordinary updates can follow the regular schedule. Resubmitting does not guarantee immediate crawling or indexing.

Sources checked

Google's sitemap, redirect, canonical, and Search Console guidance was rechecked from official sources on August 21, 2026.

<nav class="article

Where to Submit Your Sitemap in 2026: Every Search Engine & IndexNow

Thu, 16 Jul 2026 23:21:32 +0000

Where to Submit Your Sitemap in 2026: Every Search Engine & IndexNow

July 2026 11 min read by Jacob Campbell

A sitemap tells search engines exactly which pages exist on your site and when they last changed. Publishing one is only half the job — you also have to submit it so each engine (and increasingly, each AI answer engine) knows where to look. This is the complete 2026 list of where to register your sitemap, plus the modern shortcut, IndexNow, that gets new pages discovered in minutes instead of weeks.

The short version

You do not need an account on dozens of engines. In practice, three moves cover the entire English-speaking web and most AI crawlers: submit to Google, submit to Bing (which also feeds Yahoo! and DuckDuckGo), and turn on IndexNow. Add the regional engines below only if you actually target those countries.

Every place to submit your sitemap

Search engine	Region / note	Action required
Google	Global	Submit your sitemap in Google Search Console → Indexing → Sitemaps.
Bing	Global (Microsoft)	Submit in Bing Webmaster Tools. Also supports IndexNow.
Yahoo!	Global	Powered by Bing — your Bing submission already covers Yahoo!. No separate step.
DuckDuckGo	Global (privacy-focused)	Sources results from Bing — covered by your Bing submission. No separate step.
Yandex	Russia (~58% share)	Register and submit via Yandex.Webmaster. Supports IndexNow.
Baidu	China (~65% share)	Use Baidu Webmaster Tools (站长工具) to submit. Requires a verified account.
Naver	South Korea (~54% share)	Submit through Naver Search Advisor (서치어드바이저).
Seznam.cz	Czech Republic	Submit via Seznam Webmaster, or simply use IndexNow.

Google

Google is non-negotiable. Verify your domain in Google Search Console (DNS verification is the most durable method), then open Indexing → Sitemaps, enter sitemap.xml, and submit. Google will report how many URLs it discovered and flag any parsing errors. Google also reads the Sitemap: directive in your robots.txt, so keep both in sync.

Bing (and Yahoo! + DuckDuckGo for free)

Add your site to Bing Webmaster Tools — you can import your property straight from Google Search Console to skip re-verification. Submit the same sitemap URL under Sitemaps. Because Yahoo! Search and DuckDuckGo both pull their organic results from Bing's index, this one submission quietly covers all three engines. Bing is also a primary source for several AI assistants, which makes it more valuable in 2026 than its raw market share suggests.

Yandex — Russia

If you have Russian-speaking visitors, register in Yandex.Webmaster, verify ownership, and add your sitemap under the Indexing → Sitemap files section. Yandex is an IndexNow partner, so instant pings work here too.

Baidu — China

Baidu Webmaster Tools (站长工具) dominates mainland China. Submission requires a verified Baidu account and, ideally, hosting that is reachable and fast from within China. Only invest the setup time if China is a genuine market for you.

Naver — South Korea

Naver Search Advisor (서치어드바이저) is the gateway to South Korea's leading search platform. Register, verify your site, and submit the sitemap under its Request → Submit Sitemap flow.

Seznam.cz — Czech Republic

Seznam remains a meaningful engine in the Czech Republic. You can submit through Seznam Webmaster, but because Seznam supports IndexNow, the simplest route is to let your IndexNow pings do the work automatically.

IndexNow — the instant-indexing shortcut

Sitemaps are pull-based: you publish the file and wait for engines to crawl it. IndexNow is push-based — the moment a URL is added, updated, or removed, you notify the engines directly. Microsoft Bing, Yandex, and Seznam all consume IndexNow, and a submission to any one of them is shared with the others, so a single ping propagates widely.

Setup is three steps: generate an API key, host it as a text file at your site root (for example https://yourdomain.com/{key}.txt), then send a small HTTP request whenever content changes:

POST https://api.indexnow.org/indexnow
Content-Type: application/json

{
  "host": "yourdomain.com",
  "key": "your-indexnow-key",
  "urlList": [
    "https://yourdomain.com/new-page/",
    "https://yourdomain.com/updated-page/"
  ]
}

On this site, IndexNow pings fire automatically on publish — which is exactly why new articles like this one show up in Bing within minutes.

Don't forget robots.txt (and AI crawlers)

Add a single line to your robots.txt so any compliant crawler discovers your sitemap without a console submission:

Sitemap: https://yourdomain.com/sitemap.xml

This matters more every year: AI answer engines and their crawlers increasingly read robots.txt and sitemaps to decide what to ingest and cite. A clean sitemap plus this directive is the lowest-effort way to make your content machine-discoverable.

Step-by-step: submit everywhere in 30 minutes

Find and validate your sitemap. Open /sitemap.xml and confirm it loads valid XML listing your live URLs.
Submit to Google Search Console. Verify the domain, then Indexing → Sitemaps → submit sitemap.xml.
Submit to Bing Webmaster Tools. Import from Google, then submit the same sitemap — this covers Yahoo! and DuckDuckGo.
Register the regional engines you target. Yandex, Baidu, Naver, or Seznam, only where you have real audience.
Enable IndexNow. Host your key file and ping on every change for instant discovery.
Add the Sitemap line to robots.txt. So every crawler — including AI bots — finds it automatically.

Frequently asked questions

Where do I submit my sitemap?

Submit your XML sitemap in each search engine's webmaster console: Google Search Console, Bing Webmaster Tools (which also feeds Yahoo! and DuckDuckGo), Yandex.Webmaster, Baidu Webmaster Tools, Naver Search Advisor and Seznam Webmaster. For instant, ongoing discovery, also publish changes through the IndexNow protocol, which Bing, Yandex and Seznam consume directly.

Does submitting to Bing cover Yahoo! and DuckDuckGo?

Yes. Yahoo! Search and DuckDuckGo both source their web results from Bing, so a single Bing Webmaster Tools submission effectively covers all three. You do not need a separate Yahoo! or DuckDuckGo sitemap submission.

What is IndexNow and should I use it?

IndexNow is an open protocol that lets you ping search engines the instant a URL is added, updated or deleted, instead of waiting for a crawl. Microsoft Bing, Yandex and Seznam.cz support it, and a submission to one IndexNow-enabled engine is shared with the others. It is the fastest way to get new pages discovered and is strongly recommended alongside sitemap submission.

How do I submit a sitemap to Yandex, Baidu or Naver?

Register the site and verify ownership in the engine's console — Yandex.Webmaster, Baidu Webmaster Tools (站长工具) or Naver Search Advisor (서치어드바이저) — then add your sitemap URL under its sitemap/indexing section. Baidu and Naver require a verified account and are mainly worth it if you target China or South Korea respectively.

How often should I resubmit my sitemap?

You usually submit a sitemap once per engine. After that, keep the sitemap file up to date (most CMSs and custom sites regenerate it automatically) and let engines re-crawl it. Only resubmit manually after a major site change such as a migration or a large batch of new pages — or, better, ping the change through IndexNow.

Where is my sitemap URL?

For most sites it lives at /sitemap.xml (for example https://built2winweb.com/sitemap.xml). Larger sites use a sitemap index that links to several child sitemaps. Confirm the exact address in your CMS or by opening /sitemap.xml in a browser before you submit it.

Want a site that ships with a valid sitemap, robots.txt, IndexNow, and full schema markup already wired up — so it gets discovered and ranked from day one?

Get a free quote →

Last updated July 2026. Market-share figures are approximate and vary by source and date; verify current numbers for your target regions before prioritizing an engine.