Improving Google Search Console Indexing Issues with schema.org Structured Data

Introduction

While developing Digital Literary Map of Japan, a bilingual (Japanese/English) database of literary places in classical Japanese literature, Google Search Console reported 391 pages as “Crawled - currently not indexed.” Google was visiting these pages but choosing not to include them in its index. Why?

One key measure we took was implementing schema.org structured data. In this post, I’ll explain what structured data is, how we implemented it, and what improvements we expect.

What is Structured Data?

Web pages typically contain content written in HTML. Humans can look at it and understand “this is information about a place” or “this is an address,” but for search engine crawlers, everything is just a series of text strings.

Structured data is a mechanism for telling search engines what page content means in a machine-readable format. It uses the standardized vocabulary defined at schema.org and is embedded in HTML using JSON-LD (JSON for Linking Data).

For example, consider a page about “Akashi” (明石), a literary place. With HTML alone, Google cannot reliably determine whether “Akashi” refers to a place, a person’s name, or a literary work. By adding structured data, we can explicitly communicate: “This is a place in Hyogo Prefecture, Japan, at latitude 34.64, longitude 134.99, known as an utamakura (a place referenced in classical poetry).”

Basic JSON-LD Structure

Structured data is written inside <script type="application/ld+json"> tags in HTML.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Place",
  "name": "明石",
  "alternateName": "Akashi",
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 34.649312,
    "longitude": 134.992637
  }
}
</script>

Here’s what each property means:

@context: The vocabulary source. Always set to https://schema.org
@type: The type of data. Uses types defined by schema.org such as Place, WebSite, Dataset, etc.
Other properties: Specific information corresponding to the type

Types of Structured Data We Implemented

1. Place - Literary Place Detail Pages

We added Place structured data to each literary place page (approximately 300 places x 2 languages).

{
  "@context": "https://schema.org",
  "@type": "Place",
  "name": "明石",
  "alternateName": "Akashi",
  "description": "Province: Harima | Prefecture: Hyogo | A setting in The Tale of Genji...",
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 34.649312,
    "longitude": 134.992637
  },
  "address": {
    "@type": "PostalAddress",
    "addressRegion": "Hyogo",
    "addressLocality": "Harima",
    "addressCountry": "JP"
  },
  "keywords": "Utamakura, Meisho, moon, bay, Suma",
  "url": "https://literarymaps.nijl.ac.jp/spots/xxxx/"
}

The data required includes:

Place name (in Kanji and Romanized form)
Latitude and longitude
Address information (prefecture and historical province)
Description text
Related keywords

2. WebSite - Top Page

Site-wide information is described on the top page.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Digital Literary Map of Japan",
  "url": "https://literarymaps.nijl.ac.jp",
  "description": "An annotation tool for Japanese literary places",
  "inLanguage": ["ja", "en"],
  "publisher": {
    "@type": "Organization",
    "name": "Digital Literary Map of Japan",
    "url": "https://literarymaps.nijl.ac.jp",
    "logo": {
      "@type": "ImageObject",
      "url": "https://literarymaps.nijl.ac.jp/home.jpg"
    }
  }
}

3. BreadcrumbList - All Pages

This communicates the page hierarchy to Google, enabling breadcrumb display in search results.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Top",
      "item": "https://literarymaps.nijl.ac.jp/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Literary Places",
      "item": "https://literarymaps.nijl.ac.jp/spots/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Akashi / 明石"
    }
  ]
}

4. Dataset - Dataset Download Page

Structured data for listing on Google Dataset Search.

{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "name": "Digital Literary Map of Japan Dataset",
  "alternateName": "日本のデジタル文学地図 データセット",
  "description": "Structured data on Japanese literary places...",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "creator": {
    "@type": "Organization",
    "name": "Digital Literary Map of Japan"
  },
  "distribution": [
    {
      "@type": "DataDownload",
      "contentUrl": "https://literarymaps.nijl.ac.jp/downloads/dlm-dataset.xlsx",
      "encodingFormat": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
    }
  ]
}

Implementation in Nuxt

In Nuxt (a Vue.js-based framework), you can inject structured data into each page’s <head> using the useHead composable. In our project, we created a shared useSeo composable that is called from each page.

// composables/useSeo.ts

const setPlaceJsonLd = (options: {
  name: string;
  alternateName?: string;
  latitude?: number;
  longitude?: number;
  addressRegion?: string;
}) => {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Place',
    name: options.name,
    // ... other properties
  };

  useHead({
    script: [
      {
        type: 'application/ld+json',
        innerHTML: JSON.stringify(jsonLd),
      },
    ],
  });
};

Each page calls the composable as follows:

// pages/spots/[id]/index.vue

const { setPlaceJsonLd } = useSeo();

setPlaceJsonLd({
  name: attributes?.title || '',
  alternateName: attributes?.field_spot_name_romaji || '',
  latitude: attributes?.field_geo?.lat,
  longitude: attributes?.field_geo?.lon,
  addressRegion: attributes?.field_prefecture || '',
  addressLocality: attributes?.field_kuni || '',
  keywords: ['Utamakura', 'Meisho'],
});

Since the structured data is embedded into each page’s HTML during SSG (Static Site Generation) build, crawlers can read it without executing JavaScript.

Validating Structured Data

You can verify that structured data is correctly written using these tools:

Google Rich Results Test: Confirms whether Google can recognize the data
Schema.org Validator: Checks compliance with the schema.org specification
Google Search Console “Enhancements” section: Shows actual indexing status

Expected Benefits

1. Improved Index Rate

This was our primary goal. By enabling Google to correctly recognize page content as “place information,” we expect the number of “Crawled - currently not indexed” pages to decrease. Structured data serves as one of the quality signals for a page.

2. Rich Results Display

Search results may display not just the title and description, but also breadcrumbs, map information, and dataset download links.

3. Listing on Google Dataset Search

The Dataset structured data enables the dataset to be listed on Google Dataset Search, making it easier for researchers to discover the data.

4. Knowledge Graph Integration

The latitude/longitude and name information in Place structured data may be linked to Google’s Knowledge Graph. As the cultural context of utamakura and literary places is incorporated into Google’s knowledge database, pages may become more likely to appear for related search queries.

Other Search Console Fixes

Alongside adding structured data, we also implemented the following technical fixes:

Issue	Count	Fix
Page with redirect	614	Unified trailing slashes in sitemap URLs
Crawled - currently not indexed	391	Added Place structured data
Not found (404)	63	Set up .htaccess redirects and created an error page
Discovered - currently not indexed	148	Fixed sitemap URL in robots.txt (still pointed to old domain)
Duplicate issues	8	Standardized canonical URLs and og:locale:alternate

While these are not directly related to structured data, improving the site’s technical health helps optimize Google’s crawling and indexing efficiency.

Conclusion

Structured data is a means of communicating the “meaning” of web content to search engines. For digital humanities projects in particular, where content has clear structures such as places, documents, and datasets, schema.org types (Place, Dataset, BreadcrumbList, etc.) map directly to the content, making adoption highly effective.

JSON-LD can be introduced simply by adding <script> tags without modifying existing HTML, and with Nuxt’s useHead, it can be dynamically generated per page. If you’re struggling with indexing issues in Google Search Console, adding structured data is a worthwhile measure to consider.

Introduction#

What is Structured Data?#

Basic JSON-LD Structure#

Types of Structured Data We Implemented#

1. Place - Literary Place Detail Pages#

2. WebSite - Top Page#

3. BreadcrumbList - All Pages#

4. Dataset - Dataset Download Page#

Implementation in Nuxt#

Validating Structured Data#

Expected Benefits#

1. Improved Index Rate#

2. Rich Results Display#

3. Listing on Google Dataset Search#

4. Knowledge Graph Integration#

Other Search Console Fixes#

Conclusion#