How Long Does Google Take to Index a Page? The Real Numbers

This guide is for site owners and SEOs who ask how long does it take to index a page and need real numbers instead of guesses. You publish a page, you check the next day, it is not there, and stakeholders ask if something broke. This article gives typical timelines by site type, explains what happens between publish and searchable, and shows how to shorten the wait with sitemaps, internal links, crawl health and clean quality signals. You will learn how to measure your own median, what good looks like for news, products, blogs and new domains, and which fixes actually move the needle. The primary focus how long does it take to index a page appears early to lock intent.

Key takeaways

• Most established sites see fresh content indexed in hours to a few days, while new or thin pages can take one to three weeks.
• Time to crawl and time to index selection are different stages with different fixes.
• Sitemap freshness, hub linkage, server stability and uniqueness explain most timeline gaps.
• Track median hours to searchable by template for two weeks before judging progress.
• Google does not support IndexNow, so use sitemaps and crawl efficiency for Google timelines.

• The short answer for how long does it take to index a page by site type
• What happens between publish and searchable
• How long for news sites and fresh articles
• How long for products job listings and marketplaces
• How long for new domains and small blogs
• Factors that shorten or extend the wait
• How to measure and improve your own timeline
• FAQ
• Sources
• Further reading

<!-- IMAGE-PROMPT cover: 1200x630, DependsIt brand, deep charcoal #121212 background with vibrant mint #22E3B0 accent glow, thin node-network line art, Clash Display style bold heading space on left, General Sans clean labels, subject: google index timeline cover illustration, flat vector, high contrast, accessible, no photorealistic faces, no text smaller than 24px, no em dash in rendered text, export PNG then cwebp -q 82 to WEBP -->

The short answer for how long does it take to index a page by site type

This section covers the short answer with real ranges in the context of how long does it take to index a page. There is no single number, but patterns hold across many sites. Verified news pages often appear in minutes to a few hours. Fresh articles on established blogs often appear in 4 hours to 2 days. New products on mid size stores often appear in 1 to 4 days. Evergreen guides with thin detail can take 1 to 3 weeks. New domains with few links often take 2 to 4 weeks for steady coverage. Updates to already indexed pages often show in hours to 1 day. Use these as starting expectations, then measure your own medians by template. The focus keyword how long does it take to index a page stays tied to these buckets so comparisons stay fair.

Why ranges vary this much comes down to crawl demand plus selection confidence. Google visits popular, fast and frequently updated hosts more often. Published google index time studies show the same spread, and the average time to index falls when hub links and sitemaps are fresh. It also stores pages it trusts to satisfy searchers. A news homepage that changes hourly earns rapid revisits. A new blog with ten posts and no inbound links earns slower revisits. A product page with unique detail, reviews and category links earns faster storage than a variant with supplier copy and no links. None of this requires a secret trick. It reflects how crawling and quality scoring work in practice. Keep notes on what you change and when, so indexing movement links clearly to specific fixes and dates.

Google discovers most pages through crawl, not through a single submission. A submission is a hint that asks for a fresh look, but ranking and storage still depend on quality, uniqueness and site trust. That is why steady technical hygiene matters more than any one push. Keep response times low, avoid redirect chains, and return clear status codes. When the crawler can fetch quickly and without loops, each hint carries more weight and uses less of your daily allowance. Teams that accept this model stop refreshing site queries every hour and start fixing the signals that control timelines.

Google does not support IndexNow, so plan for two ecosystems. IndexNow notifies Bing, Yandex, Naver, Seznam and other partners that share the protocol, while Google relies on sitemaps, Search Console inspection and the Indexing API for eligible types. A practical setup sends updates to both paths at publish time. One worker prepares the URL list, then one branch pings IndexNow endpoints and another branch queues Google notifications within quota. Coverage improves without double counting. Your timeline expectations should split by engine, because Bing timelines can move with IndexNow while Google timelines follow crawl behavior.

Internal linking does more for indexing than most teams expect. New URLs that sit four clicks from the home page may wait days for a visit, while URLs linked from a popular category or a recent posts block get visited quickly. Add new items to relevant category pages, link related items, and keep pagination crawlable with plain anchors. Avoid loading key links only through scripts that require clicks. Simple, stable links help both Google and IndexNow driven crawlers find changes fast. When timelines slip, hub linkage is one of the first places to check.

Thin or duplicated content slows indexing because Google prioritizes pages likely to satisfy searchers. Short product descriptions copied from suppliers, empty category pages and near duplicate articles often sit in Discovered or Crawled without indexing. Add specific details such as dimensions, materials, compatibility, usage steps and original photos. Consolidate near duplicates into one strong page with redirects. Better content earns more frequent revisits and steadier indexing. Timeline reports that ignore content depth often blame crawl when selection is the real gate.

In practice, make a short runbook for timeline expectations and review it after each deploy. List who owns Search Console, where logs live, which sitemap covers the URLs and what alert fires first. Test with a small sample before wider rollout. Record status codes and timestamps so patterns appear without guesswork. If errors rise, pause, fix the root cause, then resume at half pace. Steady documented pacing beats rushing to catch up in one burst. Share the runbook with developers and editors so ownership stays clear through staff changes and seasonal peaks.

What happens between publish and searchable

This section covers what happens between publish and searchable in the context of how long does it take to index a page. Five stages sit between the publish button and a searchable result. Publish, discovery, fetch, processing and selection. Publish is when the URL first returns 200 with indexable content and a stable canonical. Discovery is when Google learns the URL from a sitemap, internal link, redirect or submission hint. Fetch is when Googlebot requests the HTML and resources. Processing covers rendering, canonicalization, duplicate comparison and quality scoring. Selection is the decision to store the page for retrieval. Each stage can add hours or days. We keep the advice practical for owners without a large team.

Discovery delays are the easiest to see. Check sitemap entry time and hub link time for twenty recent URLs. If the page went live at 09:00 but entered the sitemap at midnight, you lost fifteen hours before crawling could start well. If the page had no category link for two days, you lost more. Fetch delays come next. Slow time to first byte, 5xx spikes, redirect chains and blocked resources slow or prevent good fetches. Processing delays follow when JavaScript rendering is required, canonicals conflict, or near duplicates force comparison. Selection delays close the chain when thin detail or weak signals keep the page in Crawled without indexing. Map each slow URL to one stage before you act.

Log analysis shows what crawlers actually did, not what dashboards assume. Group hits by user agent, path template, status code and hour to see waste and priority coverage. Look for Googlebot loops on calendars, filters and search pages, plus spikes after deploys. Share weekly summaries with developers and editors so fixes target the largest waste first. Evidence from logs keeps debates short and actions clear. For timeline work, pull first Googlebot fetch per new URL and subtract publish time. That publish to fetch gap is your discovery plus politeness delay.

Quotas shape every automation decision. Many projects start with about 200 publish requests per day for URL notifications, plus per minute limits that trigger 429 when bursts arrive. Track usage in Cloud Console under APIs and Services, set alerts at 60 percent and 85 percent, and log each publish with timestamp, URL, response code and notification type. When you know your burn rate by hour, you can pace jobs, defer low priority URLs and avoid midnight surprises. Paced submission keeps timelines stable instead of spiky.

A 429 means slow down, not try harder. Read the Retry After header when present, then wait with exponential backoff and jitter before retrying. A common pattern waits 2 seconds, then 4, then 8, then 16, with a small random addition to avoid synchronized retries. Cap retries at 4 or 5 and move the URL to a delayed queue after that. Hammering the endpoint during a limit only extends the block and burns log space. Timeline collectors should also back off, checking hourly rather than every minute.

In practice, make a short runbook for publish to searchable stages and review it after each deploy. List who owns Search Console, where logs live, which sitemap covers the URLs and what alert fires first. Test with a small sample before wider rollout. Record status codes and timestamps so patterns appear without guesswork. If errors rise, pause, fix the root cause, then resume at half pace. Steady documented pacing beats rushing to catch up in one burst. Share the runbook with developers and editors so ownership stays clear through staff changes and seasonal peaks.

For background on fetch behavior, see how to read the crawl stats report which explains how request patterns relate to coverage.

<!-- IMAGE-PROMPT diagram-01: 1600px max, DependsIt brand mint #22E3B0 on charcoal #121212, node-network line art, Clash Display style headings feel with General Sans clean labels, subject: google index timeline diagram with publish crawl and index nodes, flat vector, accessible, no em dash in rendered text -->

How long for news sites and fresh articles

This section covers how long news and fresh articles take in the context of how long does it take to index a page. News moves fastest when the site follows news publisher practices. A valid news sitemap, frequently linked homepage, fast responses and original reporting help pages appear in minutes to a few hours. Top Stories eligibility and news sitemap freshness matter more than generic sitemap pings. Without those, even timely articles can take 8 to 24 hours. Fresh articles on non news blogs typically take 4 hours to 2 days when sitemaps update on publish and hub links appear quickly. When either signal lags, the range stretches to 3 to 5 days. We keep the advice practical for owners without a large team.

Checklist for fast news style indexing starts with the sitemap. List only recent articles from the last two days in the news sitemap, keep titles and dates accurate, and update on publish rather than on a nightly job. Link new stories from the homepage and section fronts within minutes. Keep article HTML fast and server rendered so the crawler sees headline, date and body without running heavy scripts. Avoid changing the URL or headline slug after publish, because each change restarts canonical evaluation. Record publish, sitemap and hub link times for each story so the newsroom sees which step slips.

Freshness signals beyond the sitemap also help. An updated category page that lists the latest stories with timestamps invites rapid revisits. A stable section structure helps Google learn where fresh items appear. Clean date markup with visible dates and consistent time zones reduces confusion. Original quotes, data and photos increase selection confidence. Syndication without canonicals works against you, because duplicates force comparison and delay storage. If rivals syndicate less and link faster, their timelines will beat yours even with similar text quality.

The Google Indexing API only documents JobPosting and BroadcastEvent pages, which covers job listings and livestream video. Many site owners still test it for product or article URLs, but that use is off label and results vary. Google may process the hint, ignore it, or throttle it. State this plainly to stakeholders. Use the API for eligible content first, and rely on sitemaps, internal links and IndexNow for broad coverage on other page types. News teams should prioritize news sitemap and hub discipline over off label API use.

Speed and stability raise effective crawl capacity. Compress images, cache HTML at the edge where safe, trim heavy scripts and keep time to first byte steady under load. Monitor 5xx rate, redirect chains and DNS time alongside crawl stats. When the host answers quickly and consistently, Google can do more useful work per minute without raising risk for shoppers and readers. During breaking events, freeze non urgent deploys so origin stays stable while crawl demand spikes.

Sitemaps remain the backbone of discovery. A clean article sitemap lists only canonical, indexable URLs that return 200 and load quickly. Split large archives into chunks of 10000 to 40000 URLs, compress with gzip, and reference each chunk from a sitemap index. Update the lastmod field only when content truly changes. Submit the index in Search Console and keep it reachable. A tidy sitemap reduces wasted fetches and leaves room for priority pages. For news, keep the dedicated news sitemap separate and small.

In practice, make a short runbook for news timelines and review it after each deploy. List who owns Search Console, where logs live, which sitemap covers the URLs and what alert fires first. Test with a small sample before wider rollout. Record status codes and timestamps so patterns appear without guesswork. If errors rise, pause, fix the root cause, then resume at half pace. Steady documented pacing beats rushing to catch up in one burst. Share the runbook with developers and editors so ownership stays clear through staff changes and seasonal peaks.

How long for products job listings and marketplaces

This section covers how long products, job listings and marketplaces take in the context of how long does it take to index a page. Catalog timelines depend on scale and churn. New products on a mid size store with clean sitemaps and category links often appear in 1 to 4 days. Variants with thin supplier copy can take 1 to 2 weeks or stay in Discovered without indexing. Price and stock updates to already indexed products often show in hours to 1 day because the URL already has signals. Marketplaces with thousands of daily adds see wider spreads. Popular categories move in hours, long tail seller pages can take weeks. Job listings eligible for structured markup and timely submission can move in hours to 2 days when markup validates and the submission path is correct. We keep the advice practical for owners without a large team.

Product detail decides selection speed. Pages with unique descriptions, specific attributes, compatibility notes, original photos and reviews give Google reason to store. Pages with short supplier text, missing attributes and no reviews look interchangeable, so Google waits. Category linkage decides crawl speed. New items linked from best seller categories and curated collections get visited quickly. Items that appear only in paginated feeds or faceted URLs wait longer. Sitemap structure decides discovery clarity. List only canonical buyable URLs, remove out of stock dead ends that return 404, and keep lastmod honest. Each of these trims days from the timeline.

• Step 1: Export twenty new products with publish time, category, sitemap time and first hub link time.
• Step 2: Check logs for first Googlebot fetch and record the publish to fetch gap.
• Step 3: Check coverage for Discovered, Crawled without indexing, or Valid.
• Step 4: Fix the dominant stage once per template, not per SKU.
• Step 5: Recompute median hours after one full crawl cycle.

Crawl capacity is often misunderstood. For small sites it rarely limits indexing, but for catalogs with 50000 to 500000 URLs it shapes what gets visited each day. Facets, session parameters, internal search results and duplicate variants can trap crawlers in low value loops. Use robots rules to block filtered views, use canonical tags to consolidate variants, and link best sellers from the home page and category hubs. Fewer dead ends means faster visits to new and updated pages. Marketplace teams should audit facet crawl waste before buying more submission tools.

Robots directives and meta tags can silently block indexing. A stray noindex in a template, an X Robots Tag header from a staging config, or a disallow in robots that covers new paths will keep pages out even after successful submission. Audit headers with a fetch tool, render pages as Googlebot, and check the coverage report for Excluded by noindex or Blocked by robots. Fix the template once rather than patching URLs one by one. For marketplaces, check seller templates separately, because one bad include can noindex thousands of pages at once.

Canonical tags decide which URL keeps the indexing credit. If variants with color, size or tracking parameters lack a canonical, Google may pick a different URL or delay indexing while it compares duplicates. Point each variant to the preferred canonical, keep the canonical self referencing on the main URL, and make sure sitemaps list only canonicals. For translated or regional pages, add hreflang and keep each locale self consistent. Clean signals shorten the decision time. Product feeds with parameter URLs benefit most from this cleanup.

In practice, make a short runbook for catalog timelines and review it after each deploy. List who owns Search Console, where logs live, which sitemap covers the URLs and what alert fires first. Test with a small sample before wider rollout. Record status codes and timestamps so patterns appear without guesswork. If errors rise, pause, fix the root cause, then resume at half pace. Steady documented pacing beats rushing to catch up in one burst. Share the runbook with developers and editors so ownership stays clear through staff changes and seasonal peaks.

To separate quality stalls from discovery stalls, read why pages stay discovered but not indexed and map each slow SKU to one stage.

How long for new domains and small blogs

This section covers how long new domains and small blogs take in the context of how long does it take to index a page. New sites start slower. Expect 2 to 4 weeks for steady coverage of core pages, with some URLs appearing in days and others waiting longer. This is normal while Google learns crawl rhythm, quality and demand. Small blogs with clean setups often see first posts indexed in 3 to 7 days, then faster as internal links and return visits build. Thin launch content with five short posts and no links can take longer, because there is little for quality scoring to trust. Patience plus clean signals beats repeated resubmission. We keep the advice practical for owners without a large team.

Launch checklist matters more than submission volume. Verify the correct Search Console property, submit a small clean sitemap with only canonical 200 URLs, link all key pages from the homepage and navigation, and keep robots open for those paths. Publish enough useful detail to stand alone, with original examples and clear structure. Earn a few relevant links from real pages rather than directories. Keep the host fast and stable through the first month. Each of these raises both crawl rate and selection confidence. Avoid launching with hundreds of thin tag and filter URLs, because they dilute attention from core pages.

Search Console verification is the gate for any Google workflow. The property must be verified with the correct scheme and subdomain, and team access must match the property type. Domain properties and URL prefix properties behave differently, so confirm which one you use before debugging coverage. If you see permission issues, check sharing settings first, then property match, then URL exactness. Most access confusion traces to a missed property detail, not to code. Keep verification stable through launch so history stays continuous.

Google discovers most pages through crawl, not through a single submission. A submission is a hint that asks for a fresh look, but ranking and storage still depend on quality, uniqueness and site trust. That is why steady technical hygiene matters more than any one push. Keep response times low, avoid redirect chains, and return clear status codes. When the crawler can fetch quickly and without loops, each hint carries more weight and uses less of your daily allowance. New site owners should publish steadily, link cleanly and measure weekly rather than hourly.

Thin or duplicated content slows indexing because Google prioritizes pages likely to satisfy searchers. Short posts without examples, empty category pages and near duplicate location pages often sit in Discovered or Crawled without indexing. Add specific details such as steps, screenshots, data, dimensions and original photos. Consolidate near duplicates into one strong page with redirects. Better content earns more frequent revisits and steadier indexing. For new domains, depth on ten pages beats thin breadth on one hundred.

In practice, make a short runbook for new site timelines and review it after each deploy. List who owns Search Console, where logs live, which sitemap covers the URLs and what alert fires first. Test with a small sample before wider rollout. Record status codes and timestamps so patterns appear without guesswork. If errors rise, pause, fix the root cause, then resume at half pace. Steady documented pacing beats rushing to catch up in one burst. Share the runbook with developers and editors so ownership stays clear through staff changes and seasonal peaks.

Factors that shorten or extend the wait

This section covers factors that shorten or extend the wait in the context of how long does it take to index a page. Six factors dominate. Sitemap freshness, internal demand through links, server speed and stability, content uniqueness and depth, canonical clarity, and robots plus meta eligibility. Improve the first three to speed discovery and fetching. Improve the next three to speed processing and selection. Teams that work in this order see faster gains, because discovery fixes show in days while quality fixes compound over weeks. We keep the advice practical for owners without a large team.

Sitemap freshness shortens discovery. Event driven updates on publish beat nightly rebuilds. A clear page index timeline with publish, sitemap and first crawl timestamps reveals whether discovery or selection causes the index delay google site owners often report. Honest lastmod beats bulk rewrites that mark every URL as new. Small focused sitemaps beat giant files with dead URLs. Internal demand shortens revisit rate. Links from homepage, category hubs and recent blocks tell Google which pages matter now. Contextual links from related articles help evergreen depth. Server speed shortens fetch capacity. Fast time to first byte, low 5xx rate and clean DNS let Google do more useful work per minute. Each of these is measurable in logs and Search Console, so track them weekly.

• Shortener 1: Publish triggered sitemap with honest lastmod and only canonical 200 URLs.
• Shortener 2: Hub links from homepage and category within an hour of publish.
• Shortener 3: Fast stable responses with no redirect chains and no 5xx spikes.
• Extender 1: Thin or duplicated detail that keeps pages in Crawled without indexing.
• Extender 2: Variant canonicals and parameter URLs that split signals.
• Extender 3: Stray noindex, robots blocks or JavaScript only content and links.

A 403 usually points to permissions or scope. Confirm the service account email has Owner access in Search Console, confirm the OAuth scope includes the indexing scope, and confirm the JSON key file matches the active key in Cloud Console. Check clock skew on the server, since JWT auth fails when time drifts by more than a few minutes. Rotate keys on a schedule, store them in a secret manager, and never paste private keys into chat tools or shared docs. The same care applies to any automation that touches indexing. Scoped keys and clean logs prevent timeline gaps caused by failed jobs.

Canonical tags decide which URL keeps the indexing credit. If variants with color, size or tracking parameters lack a canonical, Google may pick a different URL or delay indexing while it compares duplicates. Point each variant to the preferred canonical, keep the canonical self referencing on the main URL, and make sure sitemaps list only canonicals. For translated or regional pages, add hreflang and keep each locale self consistent. Clean signals shorten the decision time. Audit canonicals by template, because one template fix can move hundreds of URLs at once.

In practice, make a short runbook for wait factors and review it after each deploy. List who owns Search Console, where logs live, which sitemap covers the URLs and what alert fires first. Test with a small sample before wider rollout. Record status codes and timestamps so patterns appear without guesswork. If errors rise, pause, fix the root cause, then resume at half pace. Steady documented pacing beats rushing to catch up in one burst. Share the runbook with developers and editors so ownership stays clear through staff changes and seasonal peaks.

For official guidance on rendering and fetch, see Search Central crawling docs which explain politeness, budget and host load.

How to measure and improve your own timeline

This section covers how to measure and improve your own timeline in the context of how long does it take to index a page. Measurement starts with a simple sheet. List each new URL with publish time, sitemap time, hub link time, first Googlebot fetch and first searchable hour. Compute hours from publish to searchable. Report median, 75th percentile and share in 24 hours by template. Do this for two weeks with at least twenty URLs per template. Do not judge on three URLs or on a holiday week. Stable medians reveal the real system. Keep notes on what you change and when, so indexing movement links clearly to specific fixes and dates.

Improvement follows the dominant gap. If publish to sitemap exceeds two hours, move to event driven sitemap updates. Teams that study how fast google indexes fresh templates usually find hub linkage matters more than submission volume. If sitemap to first crawl is long, strengthen hub links and check crawl waste in logs. The speed of google indexing rises when origins stay fast, while a long index wait time often points to thin detail rather than crawl limits. If crawl to searchable is long, improve uniqueness, canonicals and internal demand. Fix one stage per cycle, then remeasure. Many teams try five fixes at once and cannot tell what worked. A single change per template per cycle keeps learning clean. Record status codes and timestamps so patterns appear without guesswork.

URL,publish_utc,sitemap_utc,hub_utc,first_crawl_utc,searchable_utc
/page/one,2026-09-01T09:00Z,2026-09-01T09:12Z,2026-09-01T10:00Z,2026-09-01T14:00Z,2026-09-02T08:00Z
/page/two,2026-09-01T10:00Z,2026-09-01T10:08Z,2026-09-01T11:00Z,2026-09-01T16:00Z,2026-09-02T09:00Z

Speed and stability raise effective crawl capacity. Compress images, cache HTML at the edge where safe, trim heavy scripts and keep time to first byte steady under load. Monitor 5xx rate, redirect chains and DNS time alongside crawl stats. When the host answers quickly and consistently, Google can do more useful work per minute without raising risk for shoppers and readers. Freeze risky deploys during measurement windows so timelines reflect the system, not the incident.

In practice, make a short runbook for measurement and review it after each deploy. List who owns Search Console, where logs live, which sitemap covers the URLs and what alert fires first. Test with a small sample before wider rollout. Record status codes and timestamps so patterns appear without guesswork. If errors rise, pause, fix the root cause, then resume at half pace. Steady documented pacing beats rushing to catch up in one burst. Share the runbook with developers and editors so ownership stays clear through staff changes and seasonal peaks.

<!-- IMAGE-PROMPT workflow-02: 1600px max, DependsIt brand mint #22E3B0 on charcoal #121212 or white, node-network line art, Clash Display style headings feel with General Sans clean labels, subject: index timeline workflow with measurement and review steps, flat vector, accessible, no em dash in rendered text -->

FAQ

How long does Google take to index a new page and how many days to index are normal?

Most established sites see new pages searchable in 4 hours to 4 days depending on template and signals. That days to index range covers fresh articles, products and guides on healthy domains. News can be faster, thin variants slower. Measure your median by template for two weeks. Strengthen sitemaps, hub links and uniqueness to move toward the fast end. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory.

What does an index time study say about google crawl to index time?

A typical index time study finds google crawl to index time ranges from hours for strong hubs to weeks for thin long tail pages. The crawl happens first, then rendering, canonicalization and quality scoring decide storage. Track publish to first crawl separately from crawl to searchable to see which stage dominates. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory.

Does requesting indexing in Search Console speed things up?

It can prompt a fresh look, but it is limited, queued and not instant. It does not override quality or canonical decisions. Use it for a few priority URLs, then rely on sitemaps, links and stable fetches for scale. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory.

How long do updates to indexed pages take to show?

Updates to already indexed pages often show in hours to 1 day when the URL has steady demand and fast fetches. Large rewrites, URL changes or canonical shifts can take longer while Google reprocesses signals. Keep lastmod honest and links stable. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory.

Does IndexNow make Google index faster?

No. Google does not support IndexNow. IndexNow helps Bing, Yandex, Naver, Seznam and other partners, while Google uses sitemaps, crawl efficiency and eligible API paths. Track engines separately. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory.

When should I worry about slow indexing?

Worry when medians by template stay flat for three to four weeks despite clean discovery, or when Valid coverage falls while Discovered plus Crawled without indexing rises. Audit speed, robots, canonicals and depth in that order. Fix templates once. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory.

Why is my page crawled but not indexed after a week?

Crawl without indexing usually points to selection, not discovery. Thin detail, near duplicates, weak internal demand or canonical confusion keep pages waiting. Add unique specifics, consolidate duplicates, point variants to a clean canonical and link from relevant hubs. Keep a short log of what you checked and when, so the next review starts from evidence rather than memory.

Sources

• Official crawl documentation
• Search Console help on requesting indexing

Further reading

• how internal linking speeds up indexing with examples
• fixes for crawled but not indexed pages
• a first month indexing plan for new sites
• sitemap practices that speed up discovery