<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
  <title>Rendy Andriyanto — Writing</title>
  <link>https://www.rendyandriyanto.com/writing/</link>
  <description>Senior SEO. Technical and programmatic growth for fintech, trading, and regulated products.</description>
  <language>en</language>
  <lastBuildDate>Fri, 01 May 2026 00:00:00 GMT</lastBuildDate>
  <atom:link href="https://www.rendyandriyanto.com/rss.xml" rel="self" type="application/rss+xml" />
  <generator>Next.js</generator>
  <item>
    <title>Crawl budget is a distribution problem, not a quota</title>
    <link>https://www.rendyandriyanto.com/writing/crawl-budget-distribution/</link>
    <guid isPermaLink="true">https://www.rendyandriyanto.com/writing/crawl-budget-distribution/</guid>
    <pubDate>Fri, 01 May 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[Treating crawl as a fixed allowance leads to the wrong fixes. What actually moves indexation at scale is how that crawl is distributed.]]></description>
    <content:encoded><![CDATA[<p>Most teams think about crawl budget as a number to increase. On a large site, that framing causes more harm than the problem it is trying to solve.</p><h2>The quota mental model breaks down</h2><p>The instinct is to treat crawling like a monthly data cap: spend it carefully, ask Google for more. But Googlebot does not hand out a fixed allowance. It crawls in proportion to two things: how much it wants your pages, and how cheaply it can fetch them. The lever is not <em>size</em>. It is <strong>distribution</strong>: where that crawl actually lands.</p><p>When traffic is flat at scale, the cause is almost never &quot;not enough crawl&quot;. It is crawl pouring into URLs that should not exist while the pages you care about wait in line.</p>
<h2>Find where crawl is leaking</h2><p>Server logs answer this directly. Normalize URLs into patterns, count Googlebot hits per pattern, and the waste shows itself.</p>
<pre><code>$ zcat access.log.gz | grep Googlebot \
    | awk &apos;{print $7}&apos; | sed -E &apos;s#/[0-9]+#/:id#g&apos; \
    | sort | uniq -c | sort -rn | head

 812043  /quote/:id      # transactional, ranks -&gt; keep
 430112  /news/:id       # fresh demand -&gt; keep
  58221  /tag/:id        # thin, cannibalizing -&gt; noindex
  12090  /search?q=      # infinite space -&gt; block in robots</code></pre>
<p>Two patterns here are quietly eating the budget: tag pages that duplicate intent, and an internal search space that is effectively infinite. Neither earns rankings. Both compete for the same crawl.</p><h2>Redistribute, do not request more</h2><p>The fixes are unglamorous and they work:</p><ul class="list-bullet"><li
          class=""
          style=""
          value="1"
        ><strong>Block infinite spaces</strong> (faceted search, session URLs) in robots.txt so they never enter the queue.</li><li
          class=""
          style=""
          value="2"
        ><strong>Noindex and prune</strong> thin patterns that cannibalize stronger pages.</li><li
          class=""
          style=""
          value="3"
        ><strong>Strengthen internal links</strong> to the templates that convert, so demand signals point where you want crawl to go.</li><li
          class=""
          style=""
          value="4"
        ><strong>Segment sitemaps</strong> by demand and keep them clean, so discovery tracks value.</li></ul>
<blockquote><p>Crawl budget is not a number you raise. It is a flow you direct. The work is deciding what does not deserve to be crawled.</p></blockquote>
<h2>What to measure</h2><p>Watch the ratio of crawl hits on revenue templates versus everything else, and median time-to-index for new high-value pages. When distribution improves, both move before total crawl does.</p><div class="lexical-table-container">
        <table class="lexical-table" style="border-collapse: collapse;">
          <tbody><tr class="lexical-table-row">
        <th
        class="lexical-table-cell lexical-table-cell-header-1"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Signal</p>
      </th>
    <th
        class="lexical-table-cell lexical-table-cell-header-1"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Vanity reading</p>
      </th>
    <th
        class="lexical-table-cell lexical-table-cell-header-1"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Useful reading</p>
      </th>
    
      </tr><tr class="lexical-table-row">
        <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Total crawl</p>
      </td>
    <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>&quot;Crawl went up&quot;</p>
      </td>
    <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Crawl on value templates went up</p>
      </td>
    
      </tr><tr class="lexical-table-row">
        <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Pages indexed</p>
      </td>
    <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Count of indexed URLs</p>
      </td>
    <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Share of <em>valuable</em> URLs indexed</p>
      </td>
    
      </tr><tr class="lexical-table-row">
        <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Time-to-index</p>
      </td>
    <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Site average</p>
      </td>
    <td
        class="lexical-table-cell lexical-table-cell-header-0"
        
        
        style="border: 1px solid #ccc; padding: 8px;"
      >
        <p>Median for new transactional pages</p>
      </td>
    
      </tr></tbody>
        </table>
      </div><p>Fix distribution and the quota takes care of itself.</p>]]></content:encoded>
    <category>Technical SEO</category>
  </item>
  <item>
    <title>What “YMYL” actually changes about your content workflow</title>
    <link>https://www.rendyandriyanto.com/writing/ymyl-content-workflow/</link>
    <guid isPermaLink="true">https://www.rendyandriyanto.com/writing/ymyl-content-workflow/</guid>
    <pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[Beyond the E-E-A-T checklist: the operational decisions that hold up under regulatory scrutiny in fintech and trading.]]></description>
    <content:encoded><![CDATA[<p>E-E-A-T is usually discussed as a scoring rubric. In regulated finance it is closer to an operating constraint that reshapes who writes, who reviews, and what you are allowed to claim.</p><h2>The checklist is the easy part</h2><p>Author bios, citations, and reviewed-by labels are table stakes. The harder shift is that in a Your Money or Your Life domain, the content workflow itself has to produce evidence of expertise and accuracy, not just assert it.</p><h2>What changes in practice</h2><ul class="list-bullet"><li
          class=""
          style=""
          value="1"
        ><strong>Review is a gate, not a courtesy.</strong> Subject-matter and compliance review sit in the publish path, with a record of who approved what.</li><li
          class=""
          style=""
          value="2"
        ><strong>Claims are sourced or cut.</strong> Anything about returns, risk, or regulation needs a citation or it does not ship.</li><li
          class=""
          style=""
          value="3"
        ><strong>Freshness has an owner.</strong> Rates, rules, and figures change; pages carry a real last-reviewed date and a re-review schedule.</li></ul>
<p>None of this is about gaming a quality rater. It is about being the kind of source a search engine can safely rank for a query where being wrong has consequences.</p>]]></content:encoded>
    <category>Content</category>
    <category>E-E-A-T</category>
  </item>
  <item>
    <title>Programmatic pages that don&apos;t get classified as spam</title>
    <link>https://www.rendyandriyanto.com/writing/programmatic-not-spam/</link>
    <guid isPermaLink="true">https://www.rendyandriyanto.com/writing/programmatic-not-spam/</guid>
    <pubDate>Sun, 01 Mar 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[The line between scaled content and thin content is mostly an information-gain problem. Here is how to stay on the right side of it.]]></description>
    <content:encoded><![CDATA[<p>Programmatic SEO and &quot;scaled content abuse&quot; use the same machinery. The difference Google cares about is whether each page adds information a user could not get more easily elsewhere.</p><h2>Gate generation on demand and data</h2><p>The first discipline is restraint: only generate a page where there is both real search demand and real data to populate it. A route page with no inventory, or a comparison with nothing to compare, is thin by construction.</p><h2>Engineer information gain</h2><p>Every template should answer &quot;what does this page uniquely know?&quot; If the answer is &quot;nothing the template above it does not&quot;, it should not exist as a separate URL.</p>
<p>Done well, programmatic pages are not a loophole. They are the most honest way to serve a long tail of genuine, specific intent at a scale humans cannot write by hand.</p>]]></content:encoded>
    <category>Programmatic</category>
  </item>
  <item>
    <title>Indexation at two million URLs: a field guide</title>
    <link>https://www.rendyandriyanto.com/writing/indexation-field-guide/</link>
    <guid isPermaLink="true">https://www.rendyandriyanto.com/writing/indexation-field-guide/</guid>
    <pubDate>Sun, 01 Feb 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[Discovery, rendering, and selection each fail differently at scale. A practical map of where pages get stuck and why.]]></description>
    <content:encoded><![CDATA[<p>&quot;Not indexed&quot; is not one problem. At seven figures of URLs it is at least three, and the fix depends entirely on which stage is failing.</p><h2>Discovery, rendering, selection</h2><ul class="list-bullet"><li
          class=""
          style=""
          value="1"
        ><strong>Discovery:</strong> the URL is not linked or sitemapped where crawl actually flows.</li><li
          class=""
          style=""
          value="2"
        ><strong>Rendering:</strong> the content depends on client-side execution that does not resolve cheaply.</li><li
          class=""
          style=""
          value="3"
        ><strong>Selection:</strong> Google sees it and decides it is a duplicate or not worth keeping.</li></ul><p>Treating a selection problem as a discovery problem (more sitemaps, more links) just pours crawl into pages that will be dropped anyway.</p>]]></content:encoded>
    <category>Technical SEO</category>
  </item>
  <item>
    <title>The “power of one” approach to multi-property SEO</title>
    <link>https://www.rendyandriyanto.com/writing/power-of-one/</link>
    <guid isPermaLink="true">https://www.rendyandriyanto.com/writing/power-of-one/</guid>
    <pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate>
    <description><![CDATA[When a brand is tempted to spin up microsites, one disciplined property almost always wins. A short case for centralization.]]></description>
    <content:encoded><![CDATA[<p>The reflex when launching something new is to give it its own site. For organic, that reflex usually costs more than it returns.</p><h2>Authority does not split well</h2><p>Every new domain starts from zero trust and competes with your own properties for the same queries. Consolidating topics onto one well-structured site lets links, internal connections, and crawl reinforce each other instead of diluting.</p><p>It is the approach that let a single gallery site outrank a much larger global counterpart: one property, done properly, carrying the whole topic.</p>]]></content:encoded>
    <category>Strategy</category>
  </item>
  <item>
    <title>Reading server logs like a search engine does</title>
    <link>https://www.rendyandriyanto.com/writing/reading-server-logs/</link>
    <guid isPermaLink="true">https://www.rendyandriyanto.com/writing/reading-server-logs/</guid>
    <pubDate>Mon, 01 Dec 2025 00:00:00 GMT</pubDate>
    <description><![CDATA[Analytics tells you what users did. Logs tell you what Googlebot did. For technical SEO, the second story matters more.]]></description>
    <content:encoded><![CDATA[<p>If you only look at analytics, you are watching the audience and ignoring the projectionist. Logs are where you see how the search engine actually experiences your site.</p><h2>Start with three questions</h2><ul class="list-bullet"><li
          class=""
          style=""
          value="1"
        >Which URL patterns does Googlebot spend the most time on, and do they deserve it?</li><li
          class=""
          style=""
          value="2"
        >How quickly does it return to your highest-value templates?</li><li
          class=""
          style=""
          value="3"
        >What status codes is it actually getting, pattern by pattern?</li></ul><p>Answer those and most &quot;mysterious&quot; indexation issues stop being mysterious.</p>]]></content:encoded>
    <category>Technical SEO</category>
  </item>
</channel>
</rss>
