SEO & Sitemaps

Automatic Sitemaps

Landingsite automatically generates a sitemap.xml file for your published website. This sitemap helps search engines like Google discover and index your pages.

Your sitemap is available at: https://www.yourdomain.com/sitemap.xml

If you open the sitemap in a browser, it may look like raw XML text instead of a styled webpage. That is normal. A sitemap is supposed to be an XML file for search engines, not a human-designed page.

If you try the non-www version first, Landingsite will usually redirect it to the canonical https://www. version. That redirect is expected as long as the final destination still loads the real XML file.

When submitting the sitemap to Google Search Console, use the final canonical URL: https://www.yourdomain.com/sitemap.xml.

RSS Feed Support

Landingsite does not currently generate a native RSS feed like /rss.xml for blog-style pages.

That means:

https://www.yourdomain.com/rss.xml is not a supported built-in feed URL
there is no setting in Landingsite to turn on RSS generation for your site right now
if you need RSS for a scheduling tool, newsletter service, or external blog reader, you will need an outside RSS solution or third-party feed generator for now

Submitting Your Site to Google

To help Google discover your site faster:

Create a Google Search Console account.
Verify ownership of your domain. If your domain uses Landingsite nameservers, you can ask the AI editor to add the TXT verification record for you.
Submit your sitemap URL in Google Search Console.
Request indexing for your homepage and any important pages after publishing major changes.

Search Console Verification: TXT Record vs HTML Tag

Google Search Console usually gives you two practical verification routes on Landingsite:

Option 1: Domain Property with a TXT Record

This is usually the easiest option when your domain already uses Landingsite nameservers.

In Google Search Console, choose the Domain property option.
Copy the TXT verification record Google gives you.
Add that TXT record in Landingsite from your domain settings, or paste it into the AI editor and ask the AI to add it.
Complete verification in Google Search Console.

For most Google verification records, use:

Type: TXT
Host/Name: @
Value: the full google-site-verification=... string Google provides

Do not put the record in a DS field or any DNSSEC screen. It needs to be a standard TXT record on the root domain.

If your domain is already using Landingsite nameservers, you also do not need to change the nameservers again just for Search Console verification. Just add the TXT record and wait for DNS propagation.

Option 2: URL Prefix Property with an HTML Tag

If you prefer Google’s HTML-tag method instead:

Copy the verification <meta> tag from Google Search Console.
Paste the tag into the AI chat and ask the AI to add it to the head of every page.
Publish the site again, then complete verification in Google Search Console.

If you only need Search Console verification, the TXT record route is usually simpler than the HTML tag route.

What Landingsite Can and Cannot Do in Search Console

Landingsite can help with the website side of SEO setup, such as:

keeping your site live and crawlable
generating your sitemap automatically
supporting DNS verification records when your domain uses Landingsite nameservers
serving a platform-managed robots.txt for your published site

Landingsite does not directly control your personal Google Search Console account. Landingsite also does not currently offer custom per-bot robots.txt editing.

On published sites, the built-in robots.txt is platform-managed. It is normal for the apex domain version (for example https://yourdomain.com/robots.txt) to redirect to the canonical https://www. version first, as long as the final destination still returns plain text.

If your live robots.txt already allows crawling generally with User-agent: * and Allow: /, that already covers standard search engines and AI crawlers unless a specific bot is blocked.

That means Landingsite support generally cannot:

log into Search Console for you
add or remove owners inside your Google account
confirm whether a sitemap was submitted inside your Search Console property
request indexing from inside your Search Console account on your behalf

If your website is live, your sitemap works, and your verification record is already in place, the next steps usually need to happen inside your own Google account.

If Search Console Says “Robots.txt Unreachable”

Google Search Console can sometimes report robots.txt unreachable even when your live site is healthy.

Before assuming there is a platform problem:

Open the live https://www.yourdomain.com/robots.txt URL directly and confirm it loads.
Confirm your sitemap also loads at https://www.yourdomain.com/sitemap.xml.
Re-run the Search Console live test using the canonical https://www. version of the affected page.
Request indexing again after the live test succeeds.
If the same error still appears after about 48 hours, collect a fresh screenshot with the exact URL and test time before contacting support.

If the live robots.txt, sitemap, domain, and SSL are all working normally, the report is often a temporary or cached Google-side fetch issue rather than a Landingsite publishing problem.

Showing Your Website in Google Business Profile

If you want your website to appear alongside your business on Google Maps or in your Google business listing, add your live website URL to your Google Business Profile.

This is separate from Search Console:

Google Business Profile controls the website link shown with your business listing.
Google Search Console helps Google discover and index your website content.

Before adding the link, make sure your Landingsite website is published and live on your domain.

URL Structure

Landingsite automatically redirects your domain to the https://www. version. When sharing URLs or submitting to search tools, use the https://www. format.

If you add canonical tags, make sure they also point to the same https://www. version. A mismatch between your live redirect target and your canonical URLs can confuse Google and slow down indexing.

Site-Wide vs Page-Specific SEO

Some SEO code should load on every page, and some belongs to one specific page. Ask the AI to add each at the right scope.

Site-wide (every page):

One site-wide Organization schema block
Google Search Console verification tags
Google Tag Manager head snippet
Google Analytics or other site-wide tracking scripts
Favicons or other truly global tags

Page-specific (one page only):

That page’s title tag
Meta description
Canonical tag
Open Graph or Twitter tags
A page-specific schema block like Product, FAQ, Service, or Breadcrumb

Avoid duplicating the same SEO tags site-wide and per-page. Duplicate title tags, meta descriptions, canonicals, or overlapping schema can confuse search tools and make troubleshooting harder.

Structured Data Best Practices

If you are adding JSON-LD schema markup, ask the AI to add it:

Keep one clean site-wide Organization schema that loads on every page.
Add page-specific schema only on the matching page.
Avoid adding the same schema type multiple times for the same page unless you have a clear reason.
Make sure every image, URL, and asset referenced in your schema actually loads live.
Publish the site again after changes, then re-test in Google Search Console or Google’s Rich Results Test.

If Search Console still reports unparsable structured data, the problem is usually one of these:

invalid JSON-LD syntax
duplicated or conflicting tags between global and page-level code
broken image or asset URLs
an older cached error report that Google has not refreshed yet

Updating Your Google Search Result Title

If Google is showing the wrong business name or an old page title for your website:

Ask the AI editor to update the page title and meta description for the relevant page.
Publish the website again so the new SEO details are live.
In Google Search Console, request indexing for the updated page.
Wait for Google to re-crawl the page — search results can lag behind the live site.

If the live page already shows the correct title and description, the remaining delay is usually on Google’s side rather than a Landingsite publishing issue.

Favicons in Google Search Results

If your favicon is already uploaded on your Landingsite site but Google still is not showing it in search results:

Make sure you are checking the canonical https://www.yourdomain.com/ version of the site.
Submit https://www.yourdomain.com/sitemap.xml in Google Search Console.
Request indexing for the homepage in Google Search Console.
Wait for Google to re-crawl the site — favicon updates in search results can lag behind the live site.

If the favicon is visible on the live website, the remaining delay is usually on Google’s side rather than a Landingsite publishing issue.

If the favicon is also missing from the live browser tab:

Re-add the favicon.
- If your site shows a visible favicon or site-icon field in settings, use that.
- If it does not, upload the favicon in the AI chat instead (see Adding a Favicon).
Publish the site again.
Check the live site in an incognito window.

If it still does not appear on the live site after that, contact support. That usually means the issue is not just Google search-result caching.

If Facebook or another social platform shows the wrong preview image, title, or description for your site:

Share the exact https://www.yourdomain.com/ URL rather than the apex domain.
Re-scrape the page in the platform’s debugger tool (for Facebook, use the Sharing Debugger).
If the old preview still appears, wait a bit and try again — social platforms often cache preview data.

Landingsite serves the Open Graph tags used for link previews, but third-party platforms may keep showing an older cached result until they re-scrape the page.

Why Only a Few Pages May Be Indexed

If Google has indexed only a small number of your pages, that does not always mean your site has a technical problem.

Start with these checks:

Confirm your sitemap is live at the canonical https://www.yourdomain.com/sitemap.xml URL.
In Google Search Console, make sure you verified and submitted the same https://www. property/version that your site uses live.
If you added manual canonical tags, confirm they match the same https://www. URLs instead of the non-www version.
Publish the site again after SEO changes, then request indexing for the affected pages in Search Console.
Check the exact exclusion reason in Search Console before assuming Landingsite is blocking indexing.

It is also normal for Google to delay or skip low-value utility pages such as thank-you pages, contact-confirmation pages, or other pages with very little unique content.

If your sitemap is live, your pages load normally, and there is no noindex tag, the remaining delay is often on Google’s side.

Dealing with Stale Google Results

If Google is showing old URLs that no longer exist on your site (like a /index.html page that now returns a 404):

Option 1: Add a Redirect (Recommended)

Set up a redirect from the old URL to the correct one. You can add path-level redirects in your website settings. This is the fastest way to fix the issue since it takes effect immediately for visitors.

Trailing slashes are the one case you do not need a redirect for. A URL like /services/ is already redirected (301) to /services on every Landingsite site automatically — see Redirects. You cannot add a rule for it either, because both paths are stored the same way.

Option 2: Google Search Console Removal

You can request removal of specific URLs through Google Search Console. However, this only removes the URL from search results temporarily — Google may re-crawl it later.

Why 404s Are Usually Fine

If a URL returns a 404, Google will eventually stop showing it in search results on its own. A 404 page will not be indexed, so unused URLs returning 404 are generally not a problem. Redirects are the best solution if you want to handle them proactively.

Custom 404 Pages

Landingsite returns a real 404 status for URLs that don’t exist on your site. By default, visitors see a plain platform “Page not found” page.

You can replace it with your own design. Ask the AI editor to create a custom 404 page (for example, “create a custom 404 page that matches my site and links back to the homepage”). The AI builds it as a page at /404 and wires it up so every URL that doesn’t exist on your published site shows your page, still with a proper 404 status.

A few details:

The page goes live on your next publish.
It is left out of your sitemap automatically, and you don’t need to link to it from your navigation.
If you built a not-found page some other way before this was supported, ask the AI to move that design into the /404 page — only the /404 page is included in the published site.
It only replaces the “page not found” response on your published site. It does not change what visitors see when a site is unpublished or a domain has no site attached; that platform message is not customizable per website.

Root-Level SEO Files

Landingsite does not currently support uploading arbitrary root-level files like /llms.txt to your site.

If you need search engines or AI crawlers to find that information, the current workaround is to put it on a normal crawlable page on your website.

Landingsite also does not currently have a separate AI-search or GEO setting. The best foundation for AI discovery is still the same core setup:

clear, original page content that directly answers customer questions
descriptive page titles, headings, and internal links
accurate business details and service/location pages
one clean site-wide Organization schema plus page-specific schema where it actually fits

SEO Tips for Landingsite Websites

Page titles and descriptions: Ask the AI editor to set specific page titles and meta descriptions for each page.
Heading structure: Use headings (H1, H2, H3) to organize your content. Ask the AI to structure your content with proper headings.
Image alt text: When adding images, ask the AI to include descriptive alt text.
Mobile-friendly: Landingsite websites are responsive by default, which is important for search rankings.
Page speed: Landingsite handles hosting and optimization automatically, so your site should load quickly without additional configuration.