𝗧𝗵𝗲 𝗦𝗲𝗰𝗼𝗻𝗱 𝗟𝗮𝗽: 𝗪𝗵𝗮𝘁 𝗛𝗮𝗽𝗽𝗲𝗻𝘀 𝗪𝗵𝗲𝗻 𝗬𝗼𝘂 𝗜𝗺𝗽𝗿𝗼𝘃𝗲 𝘁𝗵𝗲 𝗦𝗮𝗺𝗲 𝗖𝗼𝗻𝘁𝗲𝗻𝘁 𝗧𝘄𝗶𝗰𝗲
I run an automation that improves calculator pages every evening. It adds verified benchmarks, worked examples, and internal links. It has made 43 commits so far.
This week, the automation hit a "second lap." It revisited three pages it had already improved:
• P/E Ratio calculator (improved twice, 34 days apart) • SaaS Valuation calculator (improved twice, 35 days apart) • Book Value calculator (improved twice, 37 days apart)
I wanted to see if a second round of improvements would move the needle. The results were a reality check.
The data from Google Search Console shows the truth:
• P/E Ratio: 711 impressions, 2 clicks • SaaS Valuation: 17 impressions, 0 clicks • Book Value: 0 impressions, 0 clicks
The content is better now. It has specific meta descriptions and accurate benchmarks. But better content did not change Google's assessment of the page authority.
The automation improves the content, but it cannot instantly change how Google views the trust level of a domain. The improved pages are still sitting near the bottom of search results.
Meanwhile, the pages the automation never touched are winning.
A purchase order generator moved up 8 positions in one week. It has 20 clicks. An impression calculator has 1,041 impressions and 10 clicks. Neither page has ever been in the automation queue.
This creates a massive gap. The pages performing best are the ones I haven't touched. The pages I am working on most are barely getting any traffic.
Why is this happening?
- Authority: Financial media giants might dominate the P/E and SaaS niches. No amount of content can beat their established domain trust.
- Intent: The automation might be improving content that doesn't match how people actually search.
- Competition: The untouched pages might target less crowded query landscapes.
I am not stopping the automation. I am setting a checkpoint for July 21. I will check the data again in four weeks. If the second pass moves the rankings, I will report it. If not, I will know that doing something twice is not a fix for low authority.
Are you building programmatic SEO? Are you hitting a wall where good content results in bad rankings? Let's compare notes in the comments.
Другий етап: три калькулятори були вдосконалені двічі — ось що залишилося після першого проходу
У моєму попередньому дописі я розповідав про створення трьох різних калькуляторів: базового, наукового та спеціалізованого. Метою було змусити їх працювати, і мені це вдалося. Але, як знає будь-який розробник, перший прохід рідко є остаточним.
Перший прохід: просто зробити це працювати
Під час першого етапу моєю головною метою була функціональність. Я хотів, щоб калькулятори виконували математичні операції, обробляли введення та видавали результати. І вони це робили. Проте, коли я подивився на свій код після завершення, я побачив багато того, що потребувало покращення.
Мій початковий код був "брудним". Він мав багато дублювання, слабку обробку помилок і майже не мав тестів. Це був класичний приклад технічного боргу, який я накопичив, щоб швидше досягти результату.
Другий етап: робити це правильно
Другий етап був присвячений не просто додаванню нових функцій, а покращенню якості коду, надійності та стійкості до помилок. Ось основні аспекти, на яких я зосередився:
Рефакторинг для чистоти коду
Першим ділом я зайнявся рефакторингом. Мій початковий код мав багато дублювання. Використовуючи принцип DRY (Don't Repeat Yourself), я виніс спільну логіку в окремі модулі. Це зробило код чистішим, легшим для читання та підтримки.
Замість того, щоб копіювати логіку обробки чисел у кожному калькуляторі, я створив спільний інтерфейс та базовий клас.
Надійна обробка помилок
У першій версії обробка помилок була мінімальною. Якщо користувач вводив щось неправильне або намагався поділити на нуль, програма могла поводитися непередбачувано. Я додав валідацію вхідних даних та спеціальну обробку математичних помилок, щоб забезпечити стабільну роботу.
Тепер, замість того, щоб просто "падати", калькулятор видає зрозуміле повідомлення про помилку.
Всебічне тестування
Останнім, але не менш важливим кроком, було додавання тестів. Я написав юніт-тести для перевірки основної логіки та, що ще важливіше, для перевірки граничних випадків (edge cases).
Тепер я можу бути впевнений, що нові зміни не зламають існуючий функціонал. Тестування дозволило мені розслабитися під час рефакторингу, знаючи, що якщо я щось зламаю, тести мені про це скажуть.
Висновок
Цей процес нагадав мені, що розробка програмного забезпечення — це ітеративний процес. Перший прохід дає нам фундамент, але саме другий етап перетворює робочий код на якісний продукт.
Якщо ви хочете побачити, як ці зміни виглядають у коді, перегляньте мої репозиторії. Побачимося в наступному етапі!